This guy doesn't seem to understand the real differences between java/clojure packaging, and scripting language packaging.<p>Ruby's "gems" are <i>source</i> packages. When a gem is installed, arbitrary code is executed, C stubs (or even C <i>libraries</i>!) are compiled, and the resulting artifacts can be very different on different systems. Some Ruby gems even modify the Ruby code at install-time. The same is true for Perl (CPAN) and Python (setuptools, pip, etc)<p>Java and Clojure packages are <i>artifacts.</i> Each jar is a finished, built product. If it has JNI stubs, those stubs were pre-built against a specific version. The artifact is identical on every installed system. No arbitrary code is executed. Reasoning about the contents of a Clojure package does not require me to solve the halting problem.<p>The artifact approach is unambiguously better for any production deployment. The source-based approach found in Ruby, Perl, and Python is a problem for me more often than a solution. It is hypothetically great that I can use the same "gem" on OSX and Linux, but it is more important to me that I get consistent deployments on two different Linux systems.
They really should have added CPAN (for perl) to their list. Perl might not be the most popular language nowadays, but in my opinion, their package manager gets a lot of things right...<p>* centrally hosted<p>* mirrored all over the world<p>* packages are automatically checksummed & the checksum is compared on install<p>* is is quite easy to publish packages<p>and very important in my opinion<p>* it encourages you to write tests. Unit tests included in packages are automatically executed when it is installed. Many systems (semi)-automatically report back when the installation of a package fails. Hence you get tests on tons of platforms for your package<p>* pod documentation is automatically available on cpan.
No clear winner when npm has more dots than all of the others? What's the point in even comparing them, then?<p>I think npm's approach is pretty cool -- it sacrifices disk space for portability (package dependencies are always installed in the node_packages directory of the package root), so while you might effectively have 3 or 4 of the same coffee-script folder in your install, you don't have to worry about virtual environments for development and you don't have to worry about dependency upgrades breaking some other package. I think the nature of javascript allows this to be effective considering that many dependencies are smallish snippets of code.
The details for Maven an Lein are a bit off. They both use the same repositories (I think they even use the same library to download packages) yet they are reported as having different qualities in this area (licensing, mirrors, etc.). I don't think licenses are mandatory for either and there are tons of mirrors. You can even create your own pretty easily [1] (at least for the subset of libraries you actually use).<p>[1] <a href="http://www.sonatype.org/nexus/" rel="nofollow">http://www.sonatype.org/nexus/</a>
> Usually GEMs are not cryptographically signed! This can lead to security issues! It is possible to sign GEMs, but it’s not mandatory and most developers don’t sign their GEMs.<p>Unfortunately, Nobody Cares About Signed Gems: <a href="http://www.rubygems-openpgp-ca.org/blog/nobody-cares-about-signed-gems.html" rel="nofollow">http://www.rubygems-openpgp-ca.org/blog/nobody-cares-about-s...</a><p>We've tried making a difference in Phusion Passenger by setting an example, and supporting gem signing (<a href="http://www.modrails.com/documentation/Users%20guide%20Nginx.html#_cryptographic_verification_of_installation_files" rel="nofollow">http://www.modrails.com/documentation/Users%20guide%20Nginx....</a>). All Phusion Passenger gem releases since 4.0.0 RC 4 (1 year ago) are signed. All our other gems (default_value_for, etc) are also signed. Unfortunately not many people followed.<p>We'll continue to sign all our stuff, but it's sad that it never took off community-wide.
I have to disagree with this statement: "They learned from the failures of other package managers. It’s almost prefect!"<p>I find the following cons with NPM:<p>- shrinkwrap does not work as well as the alternatives in Bundler (yes, that's plural).<p>- specifying versions as git hashes does not verify the hash on "npm install"<p>- npm link is more awkward than using :path => in Bundler.<p>The big difference between NPM and bundler is that NPM allows common dependencies of dependencies to have different versions. This is usually awesome, except when it isn't -- it can cause subtle breakages if you try to pass an object from one dependency to another. This is very rare though, and if I had to choose, I'd choose the NPM behaviour.
One axis which matters to me which is largely unaddressed here: how easy it is to set up your own package server, and whether the package manager can deal with more than one package source at a time. It's mentioned in passing, but it would be good to know how well this works in a little more depth.<p>It's virtually trivial to set up a gem server, for instance, but I wouldn't know where to start for the others.
He missed my most crucial requirement: Can a package manager support more than it's chosen language? Am I forever consigned to vendor lock-in?<p>Every one of these tools is 100% focused on supporting a single language. They go so far as to use that language as the build spec so even attempting to bend it to another platform feels alien. It's okay if I only ever want to use Ruby or Javascript will be my thing for the next decade. But what if I want to take my existing npm or gem workflow or knowledge and apply it to a new language? I have to start all over from scratch. I'll have no idea how to fetch dependencies or package up my stuff for sharing.<p>If I start to tinker with more than a handful of languages, my head is going to be full of details on package management rather than APIs or library capabilities. Who wants that?
Great overview, but do you think it's possible to compare package managers between different programming languages? I mean they all work quite differently when it comes to dependencies, build process etc. I'm a Python coder & pretty happy with PIP and PYPI...
fwiw, julia's package manager is interesting - it's a wrapper around git. i don't know the details, but it seems to work well and allows you to have both "standard" and "in development" packages.
I personally am quite fond of Haxelib. First of all, installing Haxe with Haxelib was dirt simple, but what I like is it seems to always resolve dependencies properly, its easy to upgrade single packages, grab dev versions, or upgrade all your libraries at once. Updating the language or Haxelib itself is also easy. And its fast as hell.<p>In fact, installing the entire Haxe toolchain is the easiest I've ever experienced.
Rubygems has at least one public mirror: <a href="http://stackoverflow.com/a/17150536/437888" rel="nofollow">http://stackoverflow.com/a/17150536/437888</a><p>There are also solutions such as <a href="https://github.com/pusewicz/rubygems-proxy" rel="nofollow">https://github.com/pusewicz/rubygems-proxy</a> allowing you to cache / proxy to rubygems.org
To be exact, Composer allows you to install packages which don't have a license, but you cannot publish a package on Packagist anymore if it does not have a license (and packages which were submitted before the license became required are not updated anymore in the registry until they specify the license)
As a long time maven user who recently started using PyPi, I have to say that PyPi is a mess. I frequently get broken packages, timeouts, etc. Most python users seem to have been trained to keep local copies, and/or to download once and tarball it up, and don't see a problem.
Also worth mentioning, Maven manages dependencies but it's primarily a build system.<p>Gradle is another build system with dependency management.<p>The initial setup of publishing an artifact is high on Maven Central, but Sonatype makes it easier. Even easier is publishing to clojars.
I had real issues with NPM when trying to work on a spotty network connection and offline. It really really wanted to go and hit the network over and over to check versions.