Hi Rick,
Thanks for taking the time to reply. I discussed the same argument with Ankit Aggarwal, and here are my counter-arguments:
- It seems to me like the survey should take into account the developer population using each tool. If we are doing such a survey to see what tool a programmer coming to Swift is coming from, there is much less chance he has previous knowledge of rebar3 than of npm. The majority of the ones which are widely used seem to use
install
: I’ve updated the survey bellow by ordering them by stars on GitHub. It’s a crude approximation of developer population, but I think it’s good enough for us. - If we do end up implementing
install
to mean install to the system, how would we update the system packages?- Solution 1 would be to add a
—system/—global
flag onupdate.
In that case, that would bring inconsistency by using two different commands to “install/resolve” and one command but different flags for updating. - Solution 2 would be to introduce a different command to update, for example
upgrade
. In that case, we get into the scenario of Homebrew, where two synonymous commands (update
andupgrade
) are used to do two different things (I have a hard time remembering which is which).
- Solution 1 would be to add a
As can be seen in the table bellow, all package managers which offer both an installation for the local project and for the system always use the same commands names for both. I would vote for a system where:
install [package]
: resolves and fetches one or all packages locally in the projectinstall —system package
: fetches and installs a specific package in the systemupdate [package]
: resolves and updates one or all packages locally in the projectupdate —system package
: updates a specific package in the system
Here is the same survey you did, but with more information:
Package Manager | GitHub Stars | Language | Resolved File Name | Local Install Command | Local Update Command | System Install Command | System Update Command |
---|---|---|---|---|---|---|---|
Yarn | 24711 | JS | yarn.lock |
install |
upgrade |
global install |
global upgrade |
NPM | 12214 | JS | npm-shrinkwrap.json |
install |
update |
install -g |
update -g |
CocoaPods | 9328 | ObjC/Swift | Podfile.lock |
install |
update |
N/A | N/A |
Carthage | 9320 | ObjC/Swift | Cartfile.resolved |
bootstrap |
update |
N/A | N/A |
Composer | 9313 | PHP | composer.lock |
install |
update |
N/A | N/A |
Glide | 4349 | Go | glide.lock |
install |
update |
N/A | N/A |
Bundler | 3771 | Ruby | Gemfile.lock |
install |
update |
install (with gem) |
update (with gem) |
Pip | 3555 | Python | requirements.txt |
N/A | N/A | install |
install --upgrade |
Cargo | 2206 | Rust | Cargo.lock |
N/A | update |
N/A | N/A |
rebar3 | 622 | Erlang | rebar.lock |
get-deps |
upgrade |
N/A | N/A |
Carton | 393 | Perl | carton.lock |
install |
update |
N/A | N/A |
Pub | 40 | Dart | pubspec.lock |
get |
upgrade |
N/A | N/A |
Meteor | N/A (1) | JS | versions |
add |
update |
N/A | N/A |
Mix | N/A (2) | Elixir | mix.lock |
deps.get |
deps.update |
N/A | N/A |
- We only have the number of GitHub stars for the the whole Meteor project (37255) - so are not easily comparable with the stars for other package manager projects in the list.
- We only have the number of GitHub stars for the the whole Elixir project (9928) - so are not easily comparable with the stars for other package manager projects in the list.