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.
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.
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:
Inevitably be more efficient.
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.
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 01:13
-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