One of the things that I've found to be important for (and generally under-documented by) package managers is resolution strategy.<p>pip, for instance, eagerly resolves the highest version of a dependency first found in the tree and doesn't backtrack AFAIK [1]. Cargo sounds as though it behaves similarly, but will actually backtrack [2]. I've also seen package managers like 0install that will use SAT solvers to solve dependency constraints [3].<p>I've found lack of backtracking on conflicts to be frustrating, but I'm curious how the other two (and other conflict resolving strategies) compare in practice.<p>[1]: <a href="https://github.com/pypa/pip/issues/988" rel="nofollow">https://github.com/pypa/pip/issues/988</a><p>[2]: <a href="http://doc.crates.io/cargo/core/resolver/index.html" rel="nofollow">http://doc.crates.io/cargo/core/resolver/index.html</a><p>[3]: <a href="http://0install.net/solver.html" rel="nofollow">http://0install.net/solver.html</a>
At least three things wrong with respect to Bundler/RubyGems:<p>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).<p>2. Bundler does support vendoring. It is widely discouraged, but I take advantage of it in my app packager for deploys at work (Cartage: <a href="https://github.com/KineticCafe/cartage" rel="nofollow">https://github.com/KineticCafe/cartage</a>, specifically cartage-bundler <a href="https://github.com/KineticCafe/cartage-bundler" rel="nofollow">https://github.com/KineticCafe/cartage-bundler</a>).<p>3. RubyGems and Bundler can use alternative sources (my work applications use both public and private sources simultaneously).<p>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.<p>They should probably also look at CocoaPods and Carthage (iOS and macOS build dependencies) and whatever Swift provides.
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...<p>Using a new language is no longer a matter of cracking open a book, installing a compiler, and firing up vim. You've got to change your whole lifestyle now.
I know Dart isn't super widely used, but it's package manager, pub, is probably a good reference for this. We put a ton of work into it, and Dart users regularly single it out as one of the compelling parts of the Dart platform.<p><a href="https://www.dartlang.org/tools/pub" rel="nofollow">https://www.dartlang.org/tools/pub</a><p>It hews pretty closely to Bundler's model (versions, version ranges, lockfiles, shared dependencies), though. So I don't know if it gives you much insight beyond "Yes, another language team things Bundler is on the right track."<p>Personally, I have a hypothesis that states that all programming languages either have a package manager that works like Bundler or will end up getting one.
Perl's CPAN has tooling for diffing versions through the use of MetaCPAN (a top-notch site which every language should try to emulate). For example, here is a diff of the URI distribution:<p><a href="https://metacpan.org/diff/file?target=ETHER%2FURI-1.71%2F&source=ETHER%2FURI-1.69%2F" rel="nofollow">https://metacpan.org/diff/file?target=ETHER%2FURI-1.71%2F&so...</a><p>This information is also available through an API for integration into command line tools.
I don't get why "pip" is checked in "Has separate manifest and lock files". Actually it doesn't have that feature (which Bundler for Ruby has, for instance). This very feature comes with a third-party package called "pip-tools", or possible alternatives, but raw pip doesn't have this ability directly afaik.<p>Fwiw pip isn't even able to enforce versions correctly (packages are installed as the file is read, and can conflict with previously expressed constraints). Or report installed versions correctly (it's possible that packages are half-installed or installed but not reported as such by pip commands).
One thing about Cargo's lack of 'vendoring' on the checkmark list; there is <a href="https://github.com/alexcrichton/cargo-vendor" rel="nofollow">https://github.com/alexcrichton/cargo-vendor</a> , and soon there will be <a href="https://github.com/rust-lang/cargo/pull/2857" rel="nofollow">https://github.com/rust-lang/cargo/pull/2857</a>
Since I had starting looking for an alternative to NPM I have discovered a couple of things:<p>* All current package managers are either language or OS specific. What if you have an application with code written in multiple languages?<p>* 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 and it will still install.<p>* Some package managers do better than others with regards to managing packages. I found NPM encourages dependency hell and very little management tools for dependent or installed packages.<p>* A lot of package managers seem to intermix packaging, distribution, and a registry. The registries tend to have limited names to pick from (like real estate) and can result in legal problems. Also if registration to the service catalog is required you cannot self-host or self-manage the distribution of your application.<p>I am trying to work on a solution to these problems at <a href="https://github.com/prettydiff/biddle" rel="nofollow">https://github.com/prettydiff/biddle</a>
This should probably use Stack for Haskell as well, which was designed to solve various common issues that arise when using cabal as a package manager.
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.<p>I'm not arguing the point just trying to understand the decision.
Which one allows to import multiple versions of a lib/module/package with different versions? (Not primarily but also an issue of the package manager.)