I'm starting to work on a new pub command. I've got two goals for it.
Use case 1: Pre-populating your cache (bug #16265)
The first is that it can be used to install a package into your system cache. For example, maybe you're about to go off the grid and you want to make sure you have a bunch of stuff cached locally before you fall off the Internet. pub get
does this implicitly, of course, but you may not have any packages that depend on the stuff you're downloading. You just want to pull it down.
Our specific use case is that we are starting to run tests of packages. Since hitting the network can fail, we'd like to do that separately from running pub get
so that we can handle the failure more gracefully.
The idea is you could do:
$ pub ___ some_package -v "<=2.0.0"
Where ___
is the name of this command. That will find the latest version of some_package
that matches <=2.0.0
and install it into your cache. You can call this command anywhere, you don't have to be in a package.
Use case 2: Making package binaries available from the command line (bug #7874)
Once that's in place, the next use case for this command is for working with packages that contain command line applications. Once you've used this command to pull down some package, it could then do some unspecified shenanigans to look in that package's bin
directory and put the stuff in there on your PATH.
I will not be working on that functionality just yet. Right now, I'm only focused on use case 1, but I want to design the command in anticipation of use case 2. Here's where you come in. I'd like some feedback on what that command should be called.
The command to pull down your dependencies used to be pub install
before we renamed it to pub get
. The old name still works now as an alias for get
.
We can't come up with a better name for this "put stuff in my system cache and maybe add binaries to my PATH" command than install
. So our proposal is to take that command back and make it not just be a synonym for get
anymore. It would look something like:
# Download the latest version of "foo" from pub into my cache.
$ pub install foo
# Download foo 1.0.0 from pub into my cache.
$ pub install foo -v 1.0.0
# Install foo from the Git repo at some/git/path.
$ pub install -s git some/git/path
# Download all versions of foo matching that version constraint.
$ pub install foo -v ">1.0.0 <2.0.0" --all
I'm a little iffy on some of those arguments, but you get the idea. Thoughts?
I don't look at it as saying "these are the packages that I explicitly cache" versus "these are the packages that I implicitly cache by way of
pub get
". Those two sets overlap. If you were to explicitly install a package and thenpub get
a package that depended on that,pub get
would use the one you previously cached.It's always been a tenet of pub's design that it doesn't spontaneously upgrade things on you. So, when we support putting package binaries on your PATH, there will be some manual effort required to upgrade that package.
However, that probably won't be as bad as it sounds. Our intent is that the binary on your path should be "context aware". For example, let's say you have a package
foo
that exposes somefoo
command. You explicitly install that into your cache and pub does the magic it needs to put that on your PATH.Pub will pick the most recent stable version of
foo
at the point in time that you install it. When you run foo outside of a package, that's the version of it that it will use. If you want it to use a later version, you'll need to manually upgrade this "global" foo.However, if you run foo from within a package that depends on foo, you should get the version of foo that your package depends on. Our goal is to never need to create something like virtualenv or rvm for Dart. Pub should do that isolation for you implicitly. It does that already for dependencies, so it just means we need to preserve that behavior for binaries.
Pub already has a
cache
command with subcommands (the only one islist
right now), so that's not a bad idea.remove
andpurge
are tricky because they will break existing symlinks, butadd
could work.My main concern with that is that for use case 2 where you want something on your PATH,
pub cache add
doesn't seem like the right way to express that. Maybe the right answer is to have a separate command for the two use cases.