I’m still a bit confused about the difference between adding and developing a package at a local path.
(@v1.4) pkg> add <path>/<to>/<my>/<package>
(@v1.4) pkg> dev <path>/<to>/<my>/<package>
I’ve read the part of the Pkg documentation that states:
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.
]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
What is julia actually tracking? and what will be reflected when I
I take it that the changes should not be directly reflected, but that seems highly unintuitiv if the package is at a path.
Thank you for the clarification,
dev the path it will load whatever code is at the path at the load time.
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.
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.
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.)
So that means that in this situation I would have to:
- remove the package
] rm MyPackage
- Change to whatever branch, commit etc. at the package path
- re-add the package
] add <path>/<to>/<package>
Or does simply calling
] add <path>/<to>/<package> suffice to “overwrite” it?
(It doesn’t seem like using
free is really an option here, since the package is not in a registry)
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, thank you for all the answers
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.
dev’s power really comes into play is for collaboration (via a git remote)?
In this case, if you
update the package, it will re-check the original path, recover an snapshot of any new commits, and use that, right?