Comparison of Programming Language Package Managers • Hacker News Board

Re: Comparison of Programming Language Package Managers

#91

Post by jacques_chester » Sun, Jul 31, 2016, 2:16 PM UTC

zzzcpan wrote: post #87

jacques_chester wrote: post #85

Earlier quoted context omitted.

The paths that are hard-coded are non-negotiably incompatible with how Cloud Foundry locks down its containers. Other language managers don't hard-code and will allow stuff to run from a local directory.

They (other package managers) have to rely on at least a hardcoded elf interpreter or they don't provide binaries and probably don't even handle external dependencies.

> on at least a hardcoded elf interpreter

Some rely on gcc, but again, it can be run from a local directory. Various dynamic libraries can be looked up by setting environment variables or passing parameters.

I think Nix is a great idea, but I'm not aware of an argument for hardcoding those root paths which truly holds water. It makes sense of NixOS, sure, but that's because it's an environment with top-to-bottom control.

The rest of us have to be good and share our toys.

Re: Comparison of Programming Language Package Managers

#92

Post by jacques_chester » Sun, Jul 31, 2016, 2:25 PM UTC

halostatue wrote: post #88

jacques_chester wrote: post #86

Earlier quoted context omitted.

Cartage looks neat (thought Googling it took a few tries). To me it "looks" like a buildpack, insofar as you are taking something, injecting its dependencies and producing an artifact that's ready to run by itself. If you ever whack bin/detect, bin/compile and bin/release onto it, it'll probably work well enough as a buildpack in connected environments.

Thanks. We’re going to add Node, Lua, and Elixir plug-ins soon to enable standalone running. The nice thing about making just a tarball at the end of the process is that it should be relatively easy to make anything else (Docker image, AMI, etc.) with that. https://github.com/crohr/pkgr is the only thing that’s nearly similar, and it does a few things differently than Cartage ( https://github.com/KineticCafe/cartage…

If you had an option to package the runtime, you could use the binary buildpack[0] to run Cartage tarballs.

[0] https://github.com/cloudfoundry/binary-buildpack

Re: Comparison of Programming Language Package Managers

#93

Post by tboettch » Mon, Aug 01, 2016, 3:25 PM UTC

jacques_chester wrote: post #37

knucklesandwich wrote: post #27

Earlier quoted context omitted.

Global installs are the root of a lot of headaches when building software in the same way that global mutable state is the root of a lot of headaches when developing it. Nix may be the one system package manager that is the exception to this rule (I don't have experience with it, so I can't vouch towards that, but I hear great things). However apt-get is incredibly bad at getting you the dependencies you need for a r…

> Nix may be the one system package manager that is the exception to this rule Some peers of mine recently experimented with building a Nix buildpack and concluded that it won't work. Nix has hardcoded paths for its core directories, and won't work in a security-constrained container.

Does this not work?

https://nixos.org/wiki/How_to_install_nix_in_home_(on_anothe...

I've not personally tried it. From reading that document, it seems inconvenient but possible.

My understanding is that the hard-coded paths are needed to ensure compatibility of the binary caches, since store paths are often embedded in other artifacts (e.g. RPATH in binaries, shebang line in scripts). You could always run your own cache using another prefix if that's a problem.

Re: Comparison of Programming Language Package Managers

#94

Post by mordocai » Mon, Aug 01, 2016, 4:07 PM UTC

nilliams wrote: post #75

gnoway wrote: post #71

Earlier quoted context omitted.

I think it's not bashing of npm specifically so much as it is the node ecosystem it serves and depends on; at least in my mind it's difficult to separate node from npm. That said, for what it's trying to do (read a list of deps, resolve vs. registry, download and unpack) it seems to do a fine job of it. My major complaint about npm is the choice to allow version range operators on dependency declarations. We know the…

For reproducible builds (or at least 'to get the same versions again') you should be using 'npm shrinkwrap'. (Of course there's probably more you should do to get true reproducible builds, but that goes for any package manager). The range operators are important, else you'd never be able to resolve 2 packages that want a similar versioned sup-dependency e.g. jquery 1.12 because without range operators those 2 package…

The main problems we ran into with shrinkwrap were:

It shrinkwraps everything in your current node_modules directory.

This includes platform specific dependencies that may not work on other platforms but now will cause npm install to fail instead of just printing a message about it.

So our current workflow has to be:

1. Update package.json 2. rm -rf node_modules/ 3. npm install --production # This doesn't include any of those pesky platform specific packages 4. npm shrinkwrap 5. npm install # Get the dev dependencies

As far as the other comments about npm, I just generally have more problems with it than rubygems/bundler and the general OS package managers.

Re: Comparison of Programming Language Package Managers

#95

Post by nilliams » Mon, Aug 01, 2016, 5:10 PM UTC

mordocai wrote: post #94

nilliams wrote: post #75

Earlier quoted context omitted.

For reproducible builds (or at least 'to get the same versions again') you should be using 'npm shrinkwrap'. (Of course there's probably more you should do to get true reproducible builds, but that goes for any package manager). The range operators are important, else you'd never be able to resolve 2 packages that want a similar versioned sup-dependency e.g. jquery 1.12 because without range operators those 2 package…

The main problems we ran into with shrinkwrap were: It shrinkwraps everything in your current node_modules directory. This includes platform specific dependencies that may not work on other platforms but now will cause npm install to fail instead of just printing a message about it. So our current workflow has to be: 1. Update package.json 2. rm -rf node_modules/ 3. npm install --production # This doesn't include any…

Ah okay, I've never used shrinkwrap across platforms (dev in Linux or Linux VMs, deploy to Linux). That does seem like a PITA.

> As far as the other comments about npm, I just generally have more problems with it than rubygems/bundler and the general OS package managers.

I generally don't :)

Re: Comparison of Programming Language Package Managers

#96

Post by trishume » Mon, Aug 01, 2016, 11:13 PM UTC

jacques_chester wrote: post #91

zzzcpan wrote: post #87

Earlier quoted context omitted.

They (other package managers) have to rely on at least a hardcoded elf interpreter or they don't provide binaries and probably don't even handle external dependencies.

> on at least a hardcoded elf interpreter Some rely on gcc, but again, it can be run from a local directory. Various dynamic libraries can be looked up by setting environment variables or passing parameters. I think Nix is a great idea, but I'm not aware of an argument for hardcoding those root paths which truly holds water. It makes sense of NixOS, sure, but that's because it's an environment with top-to-bottom cont…

Okay you should have clarified that in your original comment, it's not that Nix is incompatible with unprivileged containers (it includes built in support!) but only with a specific container system that isn't even the most popular one (Docker AFAIK).

As for why those paths have to be hard-coded: they don't it's a config variable you can change. When you change it you give up using other people's binaries so you have to build everything yourself, which is exactly like every other distribution system that relies on hard-coded /usr/whatever paths for binaries. The FHS standard is incompatible with Nix's guarantees and dropping it is where it gets all of its power, so it has to use something different, and it chose to make that path /nix/store/whatever

Re: Comparison of Programming Language Package Managers

#97

Post by stewbrew » Tue, Aug 02, 2016, 10:55 AM UTC

moosingin3space wrote: post #46

olalonde wrote: post #12

Earlier quoted context omitted.

Npm allows that.

How do different versions of the same package interact with npm? Since JS is a dynamic language, it seems that there could be problems if a function in one version of a package returned a value which was then fed to a function in a different version.

You typically import it like:

   var foo = require('foo');

The lib's functions are accessed solely via the foo object. There is no interaction when different libs require different versions of a lib because the access the lib via different objects/modules. This actually is the one aspect of javascript I wish other languages would copy.

Re: Comparison of Programming Language Package Managers

#98

Post by groovy2shoes » Wed, Aug 03, 2016, 8:35 PM UTC

halostatue wrote: post #54

jacques_chester wrote: post #37

Earlier quoted context omitted.

> Nix may be the one system package manager that is the exception to this rule Some peers of mine recently experimented with building a Nix buildpack and concluded that it won't work. Nix has hardcoded paths for its core directories, and won't work in a security-constrained container.

Sad face. Nix is the one package manager that looked portable enough and interesting enough to push as a “single” manager for pretty much any system.

Have you had a look at pkgsrc? I know it's not as interesting as Nix or Guix, but I've had very good luck using it on OSX and various Linux distros, as well as its natural habitat of NetBSD.

http://pkgsrc.org/