15 ms·
Which programming language has the best package manager?
- frowaway001 13y agoI'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 13y agoI'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.
- flavor8 13y agoAs 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 13y agoGood 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.
- grogenaut 13y agoI 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 13y agoWas just working on this with the npm developers. https://github.com/npm/npm/issues/4131 https://github.com/npm/npm/issues/4131
- grogenaut 13y agoI 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.
- antihero 13y agoSeems odd that they'd totally miss out Pip for Python.
- negamax 13y agoAs someone who is new to frontend/js development; Bower is a life savior.
- reiz 13y agoIt'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.
- babuskov 13y agoI find it funny that mother of all package managers, Perl's CPAN is only mentioned in a footnote.
- regularfry 13y agoDoesn't CTAN predate CPAN?
- reiz 13y agoI'm sorry for that. But I'm getting every day requests for Bower, CocoaPods and Nuget. I don't get so many requests for CPAN. But It's on my radar and I will update the blog post somewhere this year.
- tweiss 13y agoGreat 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...
- craigching 13y agoI agree, when you're solving a problem, is package management a big enough issue to influence what language you're going to choose? I think it's an interesting question and not sure of the answer. My gut says no, but others might think otherwise.
- reiz 13y agoYes. 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.
- _xo_ 13y agoThey 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 13y agoMore importantly, without CPAN, we might not have things like pip and npm.
- BugBrother 13y agoPlease 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.
- reiz 13y agoWe are constantly adding new package managers to our system. CPAN and Nuget are already on our radar. We will update the blog post in a couple months with them.
- agumonkey 13y agoAFAICR, CPAN is PM's PM, and it's been that way for as long as I can remember. When is the next Perl resurrection ?
- jackmaney 13y agoI'm picking up Python in my new job, and one thing that I dearly miss from Perl is an equivalent to Dist::Zilla (https://metacpan.org/release/Dist-Zilla https://metacpan.org/release/Dist-Zilla). After a bit of initial setup (name, PAUSE account, etc), publishing is about as easy as dzil new My::Module <build library> dzil test #Make sure the build and tests go okay <set version and add changes to changefile> dzil publish
- hapless 13y agoThis 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 13y agoThe 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.
- Anderkent 13y ago.. or they don't like the limitation of only having 1 version of any artifact installed at a time, artifacts being installed globally, etc. etc. Of course they could target Nix instead, but how many people use Nix?
- dllthomas 13y ago"Of course they could target Nix instead, but how many people use Nix?" More than use the new system they developed instead, at the outset.
- mcosta 13y agoFor all the java devs who can scape maven insanity exists ivy.
- philbarr 13y agoLots 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 13y agoGood 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.
- moondowner 13y agoAnd Gradle http://www.gradle.org/ http://www.gradle.org/
- vorg 13y agoWill Gradle ever expose an API so developers can use the same language for the build scripts as they do for the projects they're building, i.e. Groovy with Gradle for Groovy projects, and Scala with Gradle for Scala projects? The Gradle overview at http://www.gradle.org/overview http://www.gradle.org/overview says "The Gradle design is well-suited for creating another build script engine in JRuby or Jython. It just doesn't have the highest priority for us at the moment." Perhaps if Gradle easily enabled any JVM language to be used, there'd be far greater uptake. There's a few of us out here who don't like using Groovy.
- Doctor_Fegg 13y agoGEM isn't an acronym. It's just a name. Sent from my Apple MAC.
- reiz 13y agoThanks for the note. Actually I don't know why I wrote it like an acronym. I should now it better!
- rmrfrmrf 13y agoNo 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.
- reiz 13y agoNo. There is no clear winner. The point is to show how other communities are solving this problem. By comparing them you get maybe new ideas. NPM is doing a pretty good job. If they would sign their packages and make the licenses mandatory it would be the clear winner. Only 2 points are missing.
- moondowner 13y agoMore dots means the author has deeper understanding in npm and thus found more to write about it.
- reiz 13y agoActually I'm using in my daily work more Bundler and Maven. But I'm anyway a big fan of NPM.
- blueblob 13y agoIt 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 13y agoIn 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.
- bryanlarsen 13y agoI 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.
- munificent 13y agoI'd also add: - Allowing multiple versions of the same package in one application is asking for Cthulhu to climb out of the ocean and burn a whole in your mind and your program.
- reiz 13y agoI 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.
- mac1175 13y agoNo Nuget?
- reiz 13y agoNuget is on my radar. I will update the blog post in a couple months with Nuget and CPAN. It just takes some time.
- eeperson 13y agoThe 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 13y agoMaybe 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.
- spellboots 13y agoRubygems 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 13y agoBut 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 13y agoYou 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 13y agoThanks 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 :-)
- andrewcooke 13y agofwiw, 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.
- Xorlev 13y agoAlso 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 13y agoYeah, 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.
- vingt-2 13y agoC with no doubt possible.
- bwilliams 13y agoA much better title to this article would be "Comparing Programming Language Package Managers".
- reiz 13y agoYou 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 13y agoHas anyone tried doing something like npm for C? Or would we consider apt-install <whatever>-dev to be that?
- reiz 13y agoI 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 13y agoYeah, 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 13y agoThat's true. That's the disadvantage of that system. If there would be a language agnostic package manager, would you use it?
- FooBarWidget 13y ago> 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-signed-gems.html http://www.rubygems-openpgp-ca.org/blog/nobody-cares-about-s... 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.html#_cryptographic_verification_of_installation_files http://www.modrails.com/documentation/Users%20guide%20Nginx....). 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 13y agoI 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.
- marcoshalano 13y agoBundler 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 13y agoWell. You are right. Next time I will pick my words more carefully.
- regularfry 13y agoOne 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 13y agoGood point. I will take that thought into the next blog post. The next blog post will cover CPAN and Nuget, too.
- Steltek 13y agoHe 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 13y agoVery 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.
- Mikeb85 13y agoI 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.
- stof 13y agoTo 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 13y agoNils Adermann just confirmed that. I updated the blog post and the info graphic.