Note tracking a package through add is distinct from develop : changes to files in the local package repository will not immediately be reflected when loading that package. The changes would have to be committed and the packages updated in order to pull in the changes.
but I don’t understand what that means.
Say I ]add <path>/<to>/<my>/<package> and at that point in time the experiment branch of my repository is active.
I’m now tired of working on this experiment and switch back to main.
What is julia actually tracking? and what will be reflected when I import MyPackage?
I take it that the changes should not be directly reflected, but that seems highly unintuitiv if the package is at a path.
If you dev the path it will load whatever code is at the path at the load time.
If you add the path it will ask git for a snapshot of the commited code in your working copy at the add time and store that among your packages. Then it will keep loading that snapshot.
Thanks,
So that means that in my example, because the experiment branch was active at add-time that will be the snapshot that is stored.
If I want the main branch stored I have to make sure to first activate it.
follow-up:
In that case, is it possible to add multiple versions of the same package by first activating different commits (for example version tags)?
The documentation mentions how we can switch between different branches and the registry version, but is it actually possible to have several versions active simultaneously in one environment?
No. (Well, if you change uuid and name between your branches you can have them in the same environment and load them at the same time but then they are actually different packages and not different versions.)
Anytime you add or dev a package it will just replace whatever specification of the package you had previously. You also have the option of doing things like add path/to/package#master to choose a specific branch. It is easy to inspect what happens by reading the package entry in Manifest.toml in your environment.
Great answer. This makes sound pretty simple, and blows through a lot of what’s confused me about how it works.
If I’ve got this right, dev is simply a substitute for add that uses the current contents of the specified directory rather than a snapshot in the package registry.
But if that’s right, I’m still a bit confused about the often recommended use of dev <hosted get repo> and all the discussion around storage of packages under development in ~/.julia/dev/ (including activating there).
dev of a URL does a bit more than dev of a path and is basically a convenient way to have Julia make a clone of the code followed by dev of the path to the clone. If you already have a clone of the package you can just dev its path directly, in particular if you prefer it to be placed somewhere other than where Julia clones it. dev of a registered package name provides the additional service that Julia looks up the package URL in the registry for you but is otherwise the same as dev by URL.
Working with an activated package is frequently a better option than having it deved to your default environment but is not a general replacement for dev. E.g. you might be working on activated package A which depends on package B. If you also need to make local changes to B you would dev it from the environment of A. (Or you could dev both packages from an outside environment.)
Excellent, that makes sense! So as long as I’m the only developer and am working locally, activating the package serves my purpose with dev giving the additional ability to use the same code in arbitrary places and with (potentially) other packages under development.
And where dev’s power really comes into play is for collaboration (via a git remote)?
