I'd like to see how one of the oldest package managers, Perl's CPAN, stacks up.
It's in the list, and does better than basically everything else.
Comparison of Programming Language Package Managers
31–40 of 98 posts
Re: Comparison of Programming Language Package Managers
#32I'd like to see how one of the oldest package managers, Perl's CPAN, stacks up.
[deleted]
Re: Comparison of Programming Language Package Managers
#33Earlier quoted context omitted.
> * 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.
Did not know that! Thanks.
Re: Comparison of Programming Language Package Managers
#34Since 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…
I often see drive-by bashing of npm, but rarely any justification. What exactly is wrong with it?
(Aside from the lack of package integrity check, which I'll grant, sucks).
Re: Comparison of Programming Language Package Managers
#35At 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…
> It is widely discouraged
It is also widely encouraged. Some engineers:
1. Don't trust dependencies to always be there.
2. Write apps that need to work in disconnected environments -- ie with no internet connectivity.
I work on the Cloud Foundry buildpacks team for Pivotal. Being able to stage and launch apps in a disconnected environment is A Big Deal for a lot of companies.
Re: Comparison of Programming Language Package Managers
#36Call 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…
Prepare for the hate-train from developers. But I agree with you though. It's frustrating because each PM wants to install it's own version, which ends up conflicting with another PM's version, and who knows where they end up, or in what state. Apt-get rarely fails for me, but pip, gem, npm fail all the time. And who knows what version of the package they just installed, or where they got it from.
I wish devs would just tell me the libraries I need, and I'll get the packages myself.
Unless your on the bleeding edge of development, you don't need the newest versions of a lib. And you probably shouldn't be developing on the bleeding edge anyway. There's a reason apt-get is so stable, and is used everywhere.
The caveat to all that is: I hate making packages for apt-get. It's a terrible process, and I completely understand why so many devs want to avoid it.
Re: Comparison of Programming Language Package Managers
#37Call 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 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.
Re: Comparison of Programming Language Package Managers
#38Call 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…
I don't know why I'm replying to a troll, but oh well.
Apt is no more standard than pip, gem, or any of the others.
Try maintaining packages for Debian, Red Hat, Arch, Gentoo, OSX, Windows, and a dozen others, for a while, and see how quickly you change your mind.
> You've got to change your whole lifestyle now.
Oh please.
Re: Comparison of Programming Language Package Managers
#39One thing about Cargo's lack of 'vendoring' on the checkmark list; there is https://github.com/alexcrichton/cargo-vendor , and soon there will be https://github.com/rust-lang/cargo/pull/2857
On the CF buildpacks team in NYC, lack of vendoring prevented us from completing a buildpack that would work in disconnected Cloud Foundry installations.
We were sad.
Re: Comparison of Programming Language Package Managers
#40Call 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…
Prepare for the hate-train from developers. But I agree with you though. It's frustrating because each PM wants to install it's own version, which ends up conflicting with another PM's version, and who knows where they end up, or in what state. Apt-get rarely fails for me, but pip, gem, npm fail all the time. And who knows what version of the package they just installed, or where they got it from. I wish devs would j…
Actually no, it's not a terrible process, it's a misunderstood process[#].
Modern tools (debhelper 7+) allow for simple process, though one needs to
understand how the binary packages thing works.
This is a decent overview on technical details: http://vincent.bernat.im/en/blog/2016-pragmatic-debian-packa...
[#] I assume you meant the friction with the tools, not the fact that package builder needs to chase down all the dependencies and generally prepare many source tarballs to be included in a repository.