
Which programming language has the best package manager? - reiz
http://blog.versioneye.com/2014/01/15/which-programming-language-has-the-best-package-manager/
======
hapless
This guy doesn't seem to understand the real differences between java/clojure
packaging, and scripting language packaging.

Ruby's "gems" are _source_ packages. When a gem is installed, arbitrary code
is executed, C stubs (or even C _libraries_!) 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)

Java and Clojure packages are _artifacts._ 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.

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.

~~~
npsimons
_The artifact approach is unambiguously better for any production deployment._

Which is precisely why many Linux distributions use them, and "app stores"
were already a thing in Debian in the mid-90s. Every time I read about a
programming language's "package manager" I can't help but feel that the
creators of such are reinventing the wheel, poorly, and mostly to paper over
issues in backwards OSes that don't have proper package management.

~~~
matthewmacleod
Hmm. This is an appropriate implementation for an operating system, but I
don't think it's suitable for a programming language.

To take Ruby as an example - I have lots of different interpreter versions
installed. 1.8.7, 1.9.3, 2.0, 2.1, jruby, rubinius. There's some scope for
managing this in OS package managers, but it's already complex. Then for each
of these environments, I want a different set of packages with different
versions (some are compatible with older versions, and some aren't, for
example). And finally, I want different versions and combinations of these
packages for different apps that I might want to run - again, there's limited
scope to implement this in an OS package manager.

~~~
regularfry
You ideally want both. Source packages for development work, and artifacts for
deployment. I've switched to .debs for deployment. Oh so simple.

~~~
matthewmacleod
Oh yeah, don't get me wrong - that's lovely. There's nothing more frustrating
that trying to get a mildly complex Rails app deployed on a mutable server.

------
_xo_
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...

* centrally hosted

* mirrored all over the world

* packages are automatically checksummed & the checksum is compared on install

* is is quite easy to publish packages

and very important in my opinion

* 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

* pod documentation is automatically available on cpan.

~~~
pmiller2
More importantly, without CPAN, we might not have things like pip and npm.

~~~
BugBrother
Please check CPAN Testers and copy that too to the Python world.

Not only will you get comprehensive tests and reports of all the packages with
different OS/language versions, it is a great test of the language
implementation with different C compilers etc.

------
rmrfrmrf
No clear winner when npm has more dots than all of the others? What's the
point in even comparing them, then?

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.

~~~
blueblob
It appears to be biased towards npm given that one set of dots is "JSON Based"
and could have just as easily been "XML Based." I mean strictly the chart, not
the article. The article seemed fair.

~~~
reiz
In the first version of the chart I had column for "XML". But it didn't looked
good, because there was only 1 candidate for XML and that was Maven. That's
why I dropped it again. Beside that I think that XML is kind of overkill for
dependency management. JSON is just fine, much smaller and easy to read.
Having the dependency definition in native code (Python, Groovy, whatever) is
not a good decision, in my opinion, because that's a source for security
vulnerabilities.

~~~
blueblob
I understand, you make a choice that summarizes the data the best that you
can; I wasn't trying to attack you. I was trying to point out that choice of a
language for the representation of your configuration is exactly that, a
choice.

I don't know that I agree that having the dependency definition in native code
is a source of vulnerabilities; it could make the definition easier to write
for people packaging code in that language. Also, I think JSON could be
considered native code for npm since it is written in nodejs/javascript.

~~~
reiz
I didn't felt attacked. I appreciate feedback ;-) And you are right. The
choice of a language is just a choice. Dependency definition in native code is
always a security vulnerability, because by resolving the dependencies you
execute unknown code, specially if the packages are not signed. I could for
example publish a python package on PyPI with a setup.py which contains code
to delete files on your hard disk. At the moment my setup.py gets executed on
your machine you will lose some files. Something like that can not happen with
JSON, XML or YML.

------
babuskov
I find it funny that mother of all package managers, Perl's CPAN is only
mentioned in a footnote.

~~~
regularfry
Doesn't CTAN predate CPAN?

~~~
babuskov
It does, but I don't think TeX counts as programming language.

~~~
malandrew
FWIW, TeX is turing complete (as is PostScript).

------
eeperson
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).

[1] [http://www.sonatype.org/nexus/](http://www.sonatype.org/nexus/)

~~~
reiz
Maybe I was not clear enough on that point. Of course Lein is using a Maven
Repository as backend. But the official Clojure Repository is not
search.maven.org it is [https://clojars.org](https://clojars.org). And there
is no Mirror of clojars.org. Of course it's possible to mirror it, because
it's a Maven Repo. But currently nobody is doing that.

------
FooBarWidget
> 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.

Unfortunately, Nobody Cares About Signed Gems: [http://www.rubygems-openpgp-
ca.org/blog/nobody-cares-about-s...](http://www.rubygems-openpgp-
ca.org/blog/nobody-cares-about-signed-gems.html)

We've tried making a difference in Phusion Passenger by setting an example,
and supporting gem signing
([http://www.modrails.com/documentation/Users%20guide%20Nginx....](http://www.modrails.com/documentation/Users%20guide%20Nginx.html#_cryptographic_verification_of_installation_files)).
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.

We'll continue to sign all our stuff, but it's sad that it never took off
community-wide.

~~~
reiz
I have read that blog post a couple days before. To sad. I think the people
don't sign their Gems because it's some extra work and developers are lazy. I
bet the artifacts in Maven are only signed because it's mandatory. You can not
submit a unsigned artefact to search.maven.org. They will decline it. But in
the intranets of many companies their are a lot of self hosted Maven
Repositories and believe me, nobody is signing the Jars their!

If we want to have more security in the Ruby community then there is only one
way. RubyGems has to decline every unsigned Gem. Signing Gems must be
mandatory.

------
bryanlarsen
I have to disagree with this statement: "They learned from the failures of
other package managers. It’s almost prefect!"

I find the following cons with NPM:

\- shrinkwrap does not work as well as the alternatives in Bundler (yes,
that's plural).

\- specifying versions as git hashes does not verify the hash on "npm install"

\- npm link is more awkward than using :path => in Bundler.

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.

~~~
reiz
I didn't know that with the git hash. That's a good point! What I like on NPM
is that they use JSON for defining the dependencies and that the packages are
by default not installed globally. NPM and Bundler are different in some ways,
but in general they do both a good job.

------
regularfry
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.

It's virtually trivial to set up a gem server, for instance, but I wouldn't
know where to start for the others.

~~~
reiz
Good point. I will take that thought into the next blog post. The next blog
post will cover CPAN and Nuget, too.

------
Steltek
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?

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.

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?

~~~
reiz
Very good point. I didn't took that into the article because these package
managers are all build for 1 single language. But I totally get your point. A
language agnostic package manager, or at least a language agnostic repository
with a clear defined API, would be awesome! The clients could still be
different for each language, to handle language specific problems, but the
repository server could be the same.

------
tweiss
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...

~~~
reiz
Yes. I think comparison is possible and important. Of course dependencies are
handles in every language a bit differently. But on the other side they all do
the same, more or less. The differences are more on the client side.

PIP is a good tool. But in my opinion the definition of dependencies shouldn't
be in setup.py file. Because it's too easy to execute random code in a
setup.py. A JSON file is the better choice for a project file, in my opinion.

------
andrewcooke
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.

------
negamax
As someone who is new to frontend/js development; Bower is a life savior.

~~~
reiz
It's currently the only solution. There not alternatives. It's cool that they
build it, but currently it has many weak points. I hope they will add user
auth and some kind of validation soon.

------
antihero
Seems odd that they'd totally miss out Pip for Python.

~~~
reiz
PIP and Python is on the list. Look at PyPI.

~~~
collyw
Am I the only person that gets confused between PyPI and PyPy?

------
Mikeb85
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.

In fact, installing the entire Haxe toolchain is the easiest I've ever
experienced.

------
marcoshalano
Bundler is just a dependency manager, not a package manager. Is the same if
you told apt-get is a package manager. Dpkg is a real package manager.

~~~
reiz
Well. You are right. Next time I will pick my words more carefully.

------
spellboots
Rubygems has at least one public mirror:
[http://stackoverflow.com/a/17150536/437888](http://stackoverflow.com/a/17150536/437888)

There are also solutions such as [https://github.com/pusewicz/rubygems-
proxy](https://github.com/pusewicz/rubygems-proxy) allowing you to cache /
proxy to rubygems.org

~~~
reiz
But the mirror posted their doesn't work for me. I get always a Forbidden
message:
[http://mirror1.prod.rhcloud.com/mirror/ruby/](http://mirror1.prod.rhcloud.com/mirror/ruby/).
Or is it just me?

~~~
spellboots
You are not supposed to be able to hit the url in your browser. You are
supposed to use it as a gem source in a Gemfile or with the gem command line
tool.

There is also [http://gems.gzruby.org/](http://gems.gzruby.org/) if you happen
to be behind the Great Firewall of China

~~~
reiz
Thanks for the hint. I really didn't know that. I will update the blog post
with my new knowledge. One point more for Bundler/RubyGems :-)

------
stof
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)

~~~
reiz
Nils Adermann just confirmed that. I updated the blog post and the info
graphic.

------
flavor8
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.

~~~
reiz
Good point. My next package manager after Maven was Bundler/RubyGems. And it
was enlightening. I don't use so much PyPI, but I heard that the core
commuters are working on a big refactoring.

------
Xorlev
Also worth mentioning, Maven manages dependencies but it's primarily a build
system.

Gradle is another build system with dependency management.

The initial setup of publishing an artifact is high on Maven Central, but
Sonatype makes it easier. Even easier is publishing to clojars.

~~~
reiz
Yeah, that is good point. I guess should have point out that in the article.

But I still think that the initial publishing on Maven Central is more
difficult then it should be. Pretty much every other package is doing a better
Job on publishing. It took me less then a minute to publish my very first Ruby
Gem. But it took me 1 week to publish my very first Jar file on the Maven
Central.

Clojars is doing better.

------
grogenaut
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.

~~~
dmourati
Was just working on this with the npm developers.
[https://github.com/npm/npm/issues/4131](https://github.com/npm/npm/issues/4131)

~~~
grogenaut
I was actually thinking more like maven where it has a local cache that it
checks first and like everything _should_ do and not bother with the net if
there is no connection, which no desktop app seems to be able to do.

------
Doctor_Fegg
GEM isn't an acronym. It's just a name.

Sent from my Apple MAC.

~~~
reiz
Thanks for the note. Actually I don't know why I wrote it like an acronym. I
should now it better!

------
bwilliams
A much better title to this article would be "Comparing Programming Language
Package Managers".

~~~
reiz
You will laugh. That was my first title. I showed the article around, 2 days
ago, and a good friend of my told me: "You need a more provocant title!".

------
angersock
Has anyone tried doing something like npm for C?

Or would we consider apt-install <whatever>-dev to be that?

~~~
reiz
I talked to many C devs, and they all use some kind of linux native package
managers. For example apt-get or yum or RPM.

~~~
angersock
Yeah, that's what I use, but that also means that on Windows I sometimes have
annoying troubles hunting down dependencies. Then again, there would be the
temptation to somehow bolt that functionality onto cmake, and then we'd all be
doomed.

~~~
reiz
That's true. That's the disadvantage of that system. If there would be a
language agnostic package manager, would you use it?

------
mcosta
For all the java devs who can scape maven insanity exists ivy.

~~~
philbarr
Lots of people seem to be moving over to Gradle now? I don't suppose anyone
can provide an opinion on Gradle vs. Maven?

Personally I've always found Maven to be a pain, but a necessary evil for
larger projects / teams. I've tried using it for smaller personal projects and
the benefit wasn't worth the time invested.

I'd rather not invest more time learning Ivy / Gradle / anything else until
someone can convince me it's not the same old crap under a different label...

~~~
reiz
Good point! I will blog more about that. I think there is a reason for that,
why there are so many build tools out there in the Java ecosystem. Obviously
there is no clear winner and the people are not satisfied with the current
status.

------
mac1175
No Nuget?

~~~
reiz
Nuget is on my radar. I will update the blog post in a couple months with
Nuget and CPAN. It just takes some time.

------
vingt-2
C with no doubt possible.

------
frowaway001
I'd say Scala's SBT. Detractors say it's too hard, but unlike other build
tools, it let's you get the job done with minimal fuss.

~~~
tethis
I've been pleasantly surprised using SBT... it's been doing the job for me for
a year now and I haven't had any problems.

