Existe uma tentativa de distro em torno do código Python e Node (e Ruby, Lua) usar Pip, NPM e rubygems e luarocks respectivamente? Ele poderia simplesmente funcionar como um repasse do gerenciador de pacotes nativo.
Digamos, por exemplo, se eu fiz "aptitude install" em um pacote python, o apitude seria inteligente o suficiente para buscá-lo usando pip de pypi.python.org ou um espelho específico de distro com versões "estáveis" (com uma opção para usar o mais recente)
Não. A menos que você convença o pacote de pacote a suportar não apenas os principais gerenciadores de pacotes (APT, RPM, pacman), mas também os específicos de idioma (RVM, CPAN, npm etc ...), isso não está na agenda de nenhuma distribuição.
Gerentes de pacotes como esse são fáceis de instalar e configurar, não acredito que você precise passar por essa extensão.
Nota: o Fedora yum tem um comando whatprovides que pode fazer alguma grandiosidade, confira.
Para responder a sua pergunta principal ( Existe uma tentativa […]? ):
Surpreendentemente, sim. Embora não esteja relacionado com os idiomas ou ferramentas que você mencionou.
Durante anos (pelo menos 15) - muito antes de o Python ter um sistema de empacotamento estável e aceito, e muito antes do Node brilhar nos olhos de qualquer pessoa - o sistema operacional FreeBSD incluiu um sistema conhecido como “BSDPAN” que envolve o CPAN do Perl sistema de embalagem.
A idéia é que, se você instalar um módulo Perl usando as ferramentas CPAN padrão, você poderá manipular o pacote instalado usando as ferramentas padrão de empacotamento do FreeBSD. E, até certo ponto, vice-versa.
Mesmo quando eu estava ativamente envolvido na comunidade FreeBSD Ports (mais uma vez, voltando > 15 anos), nunca considerei o BSDPAN uma solução muito escalonável ou sustentável. Não tenho certeza se ainda está sendo mantido ativamente hoje (embora um rápido Google sugira que seja).
No mundo de hoje, esse empreendimento teria uma queda ainda maior por causa disso, devido à proliferação de ferramentas de instalação específicas para idiomas ... e todas as razões mencionadas por outros autores de comentários.
Eu pessoalmente prefiro deixar as versões instaladas pelo sistema das várias linguagens de programação sozinhas, não instalá-las através de um gerenciador de pacotes para todo o sistema, mas manter instalações privadas completamente independentes usando ferramentas como rbenv , pyenv , plenv , nodenv , etc. Estes não podem de forma alguma interferir com qualquer coisa instalada pelo sistema (ou gerenciador de pacotes de todo o sistema).
Não, e realmente não há necessidade disso. Estamos afogando-se nos gerenciadores de pacotes agora e não precisamos de nenhum adicional nos níveis de distribuição ( rpm , dpkg , yum , apt , aptitude , pacman , portage , etc.).
NOTA: Aqui está uma lista completa de gerenciadores de pacotes para a maioria dos Unixes, intitulada: " Lista de pacotes de software sistemas de gestão ".
A maioria das linguagens de programação tem seus próprios gerenciadores de módulos / bibliotecas / pacotes, não há nada inerentemente especial com pip ou npm .
Por acaso, gerenciar o software no nível de distribuição do OS é, na verdade, uma maneira de fazer isso. Dê uma olhada nas ferramentas como rvm , pyenv , virtualenv , virtualenvwrapper , perlbrew , Renv (R), etc ....
Eu escrevi extensivamente as respostas neste site sobre essas ferramentas e fique à vontade para verificar o meu catálogo de respostas.
O OP fez a seguinte pergunta de acompanhamento nos comentários.
I use pip and npm on a regular basis, pip almost exclusively with virtualenv. Sometimes luarocks, too. The question isnt so much about their existence. I'm more wondering if a distro maintainers would benefit from existing, prepackaged software libraries in language specific repos.
Para o qual eu respondi:
Eu diria, provavelmente não a esse ponto. Como você pode ver na minha resposta acima, já existe muito investimento nessas alternativas e adicionando um idioma. um específico apenas o tornaria mais complicado do que já é, por pouco de vantagem do ponto de vista dos mantenedores de pacotes. Eu suspeito que você esteja fazendo este b / c da sua perspectiva, seria mais fácil para uma distro apenas acessar uma biblioteca pré-existente de pacotes pré-compilados, entretanto isso exigiria que a distro usasse uma variedade de idiomas bibliotecas.
Então você estaria atacando o problema em nível onde há uma incompatibilidade de impedância entre o nível que a distro precisa ser mantida, versus o nível em que os pacotes / bibliotecas pré-construídos para uma determinada linguagem podem fornecer. / p>
Talvez haja uma espécie de problema oculto aqui, na medida em que módulos para idiomas como js, python e lua podem incluir componentes que precisam ser compilados, mas nenhum deles é realmente uma linguagem compilada. 1
Essas linguagens usam intérpretes que foram compilados a partir do C / C ++ nativo, e eles também podem usar módulos com partes escritas em C / C ++, já que essas partes irão:
Inevitavelmente, seja mais eficiente.
Permitir acesso a bibliotecas C / C ++ nativas. Se você quiser usar, por exemplo, openGL, material específico POSIX, SSL, criptografia geralmente, GUI libs (gtk, qt) e muitas outras coisas em ruby, lua, et. al. isso é absolutamente um requisito.
Assim, quando você usa o gerenciador de pacotes de uma linguagem, ele pode acabar baixando o código nativo que faz parte de um determinado módulo, então ele tem que compilar isso no seu sistema . Isso é contra a premissa geral de um gerenciador de pacotes distro, que é simplesmente baixar binários pré-compilados.
Isso é (principalmente) porque as distribuições também empacotam formas pré-compiladas de módulos populares para os idiomas cujos intérpretes eles também pré-empacotam. É um recurso , já que isso significa que você não precisa compilá-los em seu sistema. Se, em vez disso, você quiser criar módulos a partir do código-fonte usando o gerenciador de pacotes de idiomas, estará sempre livre para fazer isso!
1. "Ah, mas python ou qualquer outra coisa pode ser compilada em bytecode", etc: código de byte ainda não é executável . Byte code é uma etapa intermediária usada pela maioria dos intérpretes, incluindo java, perl, python, etc, e se destina a ser portável - o que significa que não precisa ser recompilado em plataformas diferentes - mas requer um interpretador especial para para ser executado, e esse interpretador teve que ser compilado especificamente por plataforma.
Tags package-management npm pip lua