Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparison of Programming Language Package Managers

docs.google.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Comparison of Programming Language Package Managers

#21

Post by halostatue »

ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

Because apt-get doesn’t exist on the system I use, and most system packagers can’t/won’t keep up with the rate of change of development, anyway.

CPAN, RubyGems, etc. all exist because system packaging systems are (a) specific to a particular distribution, (b) generally many versions behind the development versions, (c) really hard to get into unless you are already a system packager for a particular distribution, and (d) effectively don’t exist for two of the largest platforms where you will find users.

I’d suggest making some sort of meta-system packaging system that works for all the languages, but xkcd 927 (and I wouldn’t use it myself, anyway, because it would probably not install Ruby packages correctly and would solve things worse than NPM already does).

Re: Comparison of Programming Language Package Managers

#22

Post by halostatue »

At least three things wrong with respect to Bundler/RubyGems:

1. RubyGems is the package manager. Bundler is a meta-layer on top of that which does full dependency resolution to find the right version before installing. Bundler builds on the capabilities provided by RubyGems (and will be integrated into RubyGems in the future).

2. Bundler does support vendoring. It is widely discouraged, but I take advantage of it in my app packager for deploys at work (Cartage: https://github.com/KineticCafe/cartage, specifically cartage-bundler https://github.com/KineticCafe/cartage-bundler).

3. RubyGems and Bundler can use alternative sources (my work applications use both public and private sources simultaneously).

One thing I don’t see that would love to see tracked and solved is authenticity verification. RubyGems has support for signed gems but it’s not widely used and hasn’t really been validated as Correct.

They should probably also look at CocoaPods and Carthage (iOS and macOS build dependencies) and whatever Swift provides.

Re: Comparison of Programming Language Package Managers

#23

Post by halostatue »

steveklabnik wrote: post #7
the_mitsuhiko wrote: post #2

Cargo supports vendoring and enforces semver. Not sure why that document disagrees.

The difference is in the central repository: Elm will compare your types to the previous versions and how the versions diff, and refuse to let you upload a package that makes a backwards incompatible change without bumping the version. At least, that's my understanding of what they meant.

Elm also, according to a Changelog podcast I just heard, does not allow releasing below version 1.0.

Re: Comparison of Programming Language Package Managers

#24

Post by bluejekyll »

ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

Although, the pony is still valid that every programming language has decided to implement its own pkg mgr.

Like all things in languages, the world needs to be reimplemented. Which is too bad, but I also never see a great alternative. Eventually people want everything they work on to be in the same language, which of course has the advantage that anyone in that language can hack on it, but the disadvantage that we always start anew every time a language gets created.

Re: Comparison of Programming Language Package Managers

#25

Post by jameshart »

ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

Where's the redundancy? When you pull down a project from github, grabbing all the specific versions of libraries it needs in a way which doesn't interfere with the versions of libraries used by other projects, is a different use case than the one system package managers perform, surely?

Re: Comparison of Programming Language Package Managers

#26

Post by Gankro »

ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

Oh you know, just some silly little use cases like...

* building on not-linux -- you know, where almost all personal computers exist. Gee, wouldn't it be nice if most computers could actually compile your code?

* Having only one build config, only having to maintain one publication (ugh need to maintain deb, rpm, nix, chocolatey, brew, whatever the hell arch and suse use...)

* reproducible builds -- distros are well-known to randomly modify libs, making "foo x.y.z" in yum and apt basically random. It's not even clear to me I'll get the same thing from apt on different days!

* Iterating and collaborating on fledgling projects which rightly wouldn't be accepted into a distro -- or just iterating on a timescale smaller than "months"

* local deps -- using system-global deps (as preferred by most linux package managers) is known to be a huge nightmare for any language package manager that's tried. Hence pyvenv. Hence why so many have thrown up their hands in disgust and just started dockering all the things.

(inb4 someone comes to explain that Nix or whatever probably magically solves all these problems)

Re: Comparison of Programming Language Package Managers

#27

Post by knucklesandwich »

ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

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 reproducible build.

I've seen this argument come up a few times now, and I have a hard time reconciling this rosy view of system package managers at the center of a development process with my own experiences. That process was never as easy as "cracking open a book, installing a compiler, and firing up vim" and usually entailed a fair amount of trial and error, environment variable fiddling, and sadness from having to chase down a derelict PPA (or the equivalent) hosting the actual dependency version I need. Then more sadness as the number of projects I work on increases and my dependency versions bifurcate.

Re: Comparison of Programming Language Package Managers

#28

Post by sdegutis »

bluejekyll wrote: post #24
ryandrake wrote: post #20

Call me old fashioned, but I find it annoying that every new language nowadays seems to want to pull in its own package manager, redundantly parallel to the perfectly good one my operating system provides. I am already perfectly fine with installing my software through apt-get. Why oh why do I need pip, and gem, and npm, and CocoaPods, and cargo, and NuGet, and on and on and on... Using a new language is no longer a…

Although, the pony is still valid that every programming language has decided to implement its own pkg mgr. Like all things in languages, the world needs to be reimplemented. Which is too bad, but I also never see a great alternative. Eventually people want everything they work on to be in the same language, which of course has the advantage that anyone in that language can hack on it, but the disadvantage that we al…

You know, earlier today I was thinking, "wouldn't it be great if we all just used one programming language for everything?" And I tried to imagine which one it could be. And all had different strengths and weaknesses. C is great for raw speed, but ends up with very rigid programs, and is easy to shoot your foot in. Rust solves the second problem but not the first. Ruby solves both, but is much slower. LuaJIT solves all these, but doesn't have a great ecosystem. Etc etc etc. Every programming language exists because someone needed the trade-offs that it made, and no other language before it made them. And the package management situation of a given language is usually tied to the nature of how that language works, meaning you can't just use Homebrew to install Python and Lua and Ruby and Node and Rust packages.

Re: Comparison of Programming Language Package Managers

#29

Post by eridius »

mordocai wrote: post #18
anonymousguy wrote: post #14

Since I had starting looking for an alternative to NPM I have discovered a couple of things: * All current package managers are either language or OS specific. What if you have an application with code written in multiple languages? * NPM didn't have any kind of integrity checks for its packages, and I assume most package managers don't either. If you download a corrupt package, for example, you won't have any idea a…

> * All current package managers are either language or OS specific. What if you have an application with code written in multiple languages? guix and nix both work cross-language and cross-distro. Still OS specific though since only linux AFAIK. Also, containers partially solve this problem. > * NPM didn't have any kind of integrity checks for its packages, and I assume most package managers don't either. If you dow…

Nix runs on OS X as well.

Re: Comparison of Programming Language Package Managers

#30

Post by throwaway2016a »

jadell wrote: post #17
throwaway2016a wrote: post #15

I'm confused as to why composer (PHP) got an X for "Central package repository"... isn't Packagist a central registry? And other package managers allow packages from source. I'm not arguing the point just trying to understand the decision.

You're not actually downloading the package from Packagist. It acts only as a metadata repository that points you to a source repository. For the others, I would assume they act as both a metadata and a source repository.

Thanks for the clarification. I'm shocked it is the only one like that.
Post reply on HN