3 ms·

And then you get six different package managers on a single system for Ruby, Python, Node, Perl, X and Y? Also, how would you specify a cross-language dependen

And then you get six different package managers on a single system for Ruby, Python, Node, Perl, X and Y? Also, how would you specify a cross-language dependency, for example from a Python application to a Ruby application to a Ruby library? Should the Python-installer know how to handle "Ruby-dependencies" and what little piece of software to call to install said dependency?

lmm 14y ago
>And then you get six different package managers on a single system for Ruby, Python, Node, Perl, X and Y? I guess it would be better to have a cross-language VM - something that the CLR and the JVM are trying to do. Or it's possible to treat virtualization images (e.g. AMIs) as your execution environment and use a package manager inside that (although there are still no good package managers for C in terms of handling dependencies on conflicting versions of the same libraries). The point is that the "native" system is too inconsistent. >Also, how would you specify a cross-language dependency, for example from a Python application to a Ruby application to a Ruby library? I don't think that actually happens; you can only have a dependency where you have a common interface. If you were running the programs in Jython and JRuby you could have such a dependency, but in that case you would be able to use a JVM-oriented package manager for both. You're right though; there's no reason a package manager should be language-specific. A virtualenv/bundler-like piece of software that managed the installation of libraries in any language would be a very good thing.
- claudius 14y ago
  > I don't think that actually happens; you can only have a dependency where you have a common interface. There is always the OS as a common interface. For example, I don’t see why some application should not require a mailserver to be installed, i.e. a ‘mail’ binary to be present, even if said binary might be a native C binary rather than a Python script. I guess it all depends on what you want to do: If there is little to no interaction/overlap between applications, either because you want to keep them separate anyways[0] or because there is only one application running on a system, deploying a VM for each application makes perfect sense. On the other hand, if I had to install every library required by each application separately for said application[1], my system that currently fits nicely into 6 GB would probably require at least a few gigabytes more, and likely also more RAM. [0] Because you don’t necessarily trust the authors, for example, as appears to be the case with all the Markets/Playstore/insert-fancy-name-here. [1] This btw already exists, it’s called ‘static linking’.
  - jfb 14y ago
    I'm intrigued by NixOS [1]; it seems like it's designed to solve this exact problem. [1] http://nixos.org http://nixos.org
    - claudius 14y ago
      Whether it solves that problem appears to depend on your definition of the problem. To me, it appears as if every library required by every application was stored together with said application, and that every version of every library and application ever installed was also stored. That’s surely nice if you have large disks, but it is neither going to work for phones nor for (sensibly-priced) SSDs. I agree, though, that it does look like an interesting project, but also have to admit that I’m quite happy with the state of package management in Debian – including the idea to force everything into the dpkg/APT framework.

lmm 14y ago

>And then you get six different package managers on a single system for Ruby, Python, Node, Perl, X and Y? I guess it would be better to have a cross-language VM - something that the CLR and the JVM are trying to do. Or it's possible to treat virtualization images (e.g. AMIs) as your execution environment and use a package manager inside that (although there are still no good package managers for C in terms of handling dependencies on conflicting versions of the same libraries). The point is that the "native" system is too inconsistent. >Also, how would you specify a cross-language dependency, for example from a Python application to a Ruby application to a Ruby library? I don't think that actually happens; you can only have a dependency where you have a common interface. If you were running the programs in Jython and JRuby you could have such a dependency, but in that case you would be able to use a JVM-oriented package manager for both. You're right though; there's no reason a package manager should be language-specific. A virtualenv/bundler-like piece of software that managed the installation of libraries in any language would be a very good thing.

claudius 14y ago
> I don't think that actually happens; you can only have a dependency where you have a common interface. There is always the OS as a common interface. For example, I don’t see why some application should not require a mailserver to be installed, i.e. a ‘mail’ binary to be present, even if said binary might be a native C binary rather than a Python script. I guess it all depends on what you want to do: If there is little to no interaction/overlap between applications, either because you want to keep them separate anyways[0] or because there is only one application running on a system, deploying a VM for each application makes perfect sense. On the other hand, if I had to install every library required by each application separately for said application[1], my system that currently fits nicely into 6 GB would probably require at least a few gigabytes more, and likely also more RAM. [0] Because you don’t necessarily trust the authors, for example, as appears to be the case with all the Markets/Playstore/insert-fancy-name-here. [1] This btw already exists, it’s called ‘static linking’.
- jfb 14y ago
  I'm intrigued by NixOS [1]; it seems like it's designed to solve this exact problem. [1] http://nixos.org http://nixos.org
  - claudius 14y ago
    Whether it solves that problem appears to depend on your definition of the problem. To me, it appears as if every library required by every application was stored together with said application, and that every version of every library and application ever installed was also stored. That’s surely nice if you have large disks, but it is neither going to work for phones nor for (sensibly-priced) SSDs. I agree, though, that it does look like an interesting project, but also have to admit that I’m quite happy with the state of package management in Debian – including the idea to force everything into the dpkg/APT framework.