Is there an attempt of distro around that for Python and Node code ( and Ruby , Lua ) would use Pip, NPM and rubygems and luarocks respectively ? It could simply work as a passthrough from native package manager.

Say, for example, if i did "aptitude install" on a python package, apitude would be smart enough to go and fetch it using pip from pypi.python.org or a distro specific mirror with "stable" versions ( with an option to use the latest )


No. Unless you convince packagekit to support not only the major package managers (APT, RPM, pacman) but also the language-specific ones (RVM, CPAN, npm etc...), this is not in the agenda of any distro.

Package managers like that are easy to install and configure, I don't believe that you would need to go thru such extent.

Note: Fedora yum has a whatprovides command that can do some awesomeness, check it out.


To answer your main question (Is there an attempt […]?):

Surprisingly, yes. Though not relating to the languages or tools you mention.

For years (at least 15) — long before Python had a stable, accepted packaging system, and long before Node was a twinkle in anyone’s eye — the FreeBSD operating system has included a system known as “BSDPAN” which wraps Perl’s CPAN packaging system.

The idea being that if you install a Perl module using the standard CPAN tools, you can thereafter manipulate the installed package using standard FreeBSD packaging tools. And, to some extent, vice versa.

Even when I was actively involved int the FreeBSD Ports community (again, going back > 15 years) I never really considered BSDPAN a very scalable or maintainable solution. I’m not sure whether it’s still being actively maintained today (though a quick google suggests it is).

In today’s world, such an undertaking would have an even greater whiff off folly about it, due to the proliferation of language-specific installation tools … and all the reasons mentioned by other commenters.

I personally prefer to leave system-installed versions of the various programming languages alone, not to install them via a system-wide package manager, but rather to maintain private, completely independent installations using tools such as rbenv, pyenv, plenv, nodenv, etc. These can then in no way interfere with anything installed by the system (or system-wide package manager).


No, and there really isn't any need for it. We're drowning in package managers now and don't need any additional ones at the distro levels (rpm, dpkg, yum, apt, aptitude, pacman,portage, etc.).

NOTE: Here's a full list of package managers for most Unixes, titled:"List of software package management systems".

Most programming languages have their own module/library/package managers by the way, there isn't anything inherently special with pip or npm.

Languages and their package managers

  • Perl - cpanm, cpanplus, cpanm
  • Ruby - gems
  • Python - pip
  • Node - npm
  • R - install.packages()
  • the list goes on and on.....

Incidentally, managing software at the OS'es distribution level is actually a passe way to do so. Take a look at tools such as rvm, pyenv, virtualenv, virtualenvwrapper, perlbrew, Renv (R), etc....

I've written up answers extensively on this site about these tools feel free to check out my back catalog of answers.


The OP asked the following follow-up question in the comments.

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.

To which I replied:

I would say, probably not to that point. As you can see from my answer above, there is already a lot of investment in these alternatives, and adding a lang. specific one would just make it more complicated than it already is, for little upside from the package maintainers perspective. I suspect that you're asking this b/c from your perspective it would seem easier for a distro to just tap into a pre-existing library of pre-build packages, however this would then require the distro to tap into a variety of languages libraries.

So you'd be attacking the problem at level where there's an impedance mismatch between the level that the distro needs to be maintained, vs. the level at which the pre-built packages/libraries for a given language can provide.

  • aptitude is just a frontend for Advanced Package Tool (APT). ;) – Braiam Jan 26 '14 at 23:05
  • I know that. That list was more for effect w/o having to rattle off more names of package managers that I don't know the names of off the top of my head. 8-). BTW wikipedia agrees w/ me that it's a package mgr. en.wikipedia.org/wiki/Package_management_system – slm Jan 26 '14 at 23:22
  • 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. – kert Jan 26 '14 at 23:25
  • @kert - See my updates, let me know if that makes sense. – slm Jan 26 '14 at 23:32

Perhaps there's a sort of hidden issue here, in so far as modules for languages like js, python, and lua may include compenents that need to be compiled, but none of these is really a compiled language.1

These languages use interpreters which were compiled from native C/C++, and they can also use modules with parts written in C/C++, since those parts will:

  1. Inevitably be more efficient.

  2. Allow access to native C/C++ libraries. If you want to use, e.g., openGL, POSIX specific stuff, SSL, encryption generally, GUI libs (gtk, qt), and a great many other things in ruby, lua, et. al. this is absolutely a requirement.

So, when you use a language's package manager, it may end up downloading native code that is part of a given module, then it has to compile that on your system. This is contra the general premise of a distro package manager, which is that it simply downloads pre-compiled binaries.

That's (primarily) why the distros also package pre-compiled forms of popular modules for the languages whose interpreters they also pre-package. It's a feature, since this means you don't have to compile them on your system. If instead you want to build modules from source using the language package manager, you are always free to do that!

1. "Oh but python or whatever can be compiled into bytecode", etc: byte code is still not executable. Byte code is an intermediate step used by most interpreters including java, perl, python, etc, and is intended to be portable -- meaning it does not need to be re-compiled on different platforms -- but it requires a special interpreter in order to be executed, and that interpreter did have to be platform-specifically compiled.

  • Actually, i use both linux and macos for daily work, in a mix of virtual machines etc. On mac macports is my primary package manager and it sort of transparently either uses binary or source packages, depending on if a binary is available or no. Also on debian based systems i do dget -x and build newer packages from source on a regular basis. A binary package from native code can be viewed as mostly a cached option in that sense. And often, when a pip virtualenv install requires a compiled native library underneath, you run into strange issues with base system libraries not matching etc. – kert Jan 27 '14 at 1:13
  • Fair enough. IMO the most important reason is that the distro packager and the language packager be distinct, so that you have the option of either strategy. Some people prefer distro binaries even though the versions tend to be older because they see them as less of a gamble than a locally compiled one.... – goldilocks Jan 27 '14 at 10:00
  • ...If the language packager/library system is smart, you can configure it to install into a distinct path, then sort your system interpreter's include path so that it prefers a locally compiled version if available (or vice versa). And so on and so forth. You seem to be suggesting that people would appreciate it if the distros removed these kinds of options. If instead you mean, make the language packager an option with the distro packager, that's basically exactly the current situation + a lot of then meaningless maintenance work for the distro packager devs. – goldilocks Jan 27 '14 at 10:03
  • "A binary package from native code can be viewed as mostly a cached option" -> Which can easily take 5-10 minutes to compile on a small/busy server slice, and requires a bunch of -dev packages to boot. I'm fine with that, which is why I often prefer the language packagers. However, I'm sometimes not permitted such extravagance, and I understand that many (even: most) people, given a choice, will prefer to just download pre-compiled versions. The distros provide a service on top of what the language packagers do. Why take that away??? – goldilocks Jan 27 '14 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.