[PLEASE READ THE FIRST POST THOROUGHLY BEFORE REPLYING]
3. Managing Packages
Adding registered packages
a. [QUES] Would “current environment” be clearer? Is the default environment considered a project? I see that the next section (4) is about environments, but it seems to exclusively be about creating projects. [I don’t think anyone would notice this unless they were writing this post. Actually, is an environment the manifestation of a package? Honestly, it has not occurred to me until this precise moment to even entertain this thought, and that’s only because I am writing this post.]
Julia’s General registry
b. [TYPO] Looks like a capital letter is missing or there is an extra one.
c. [QUES] Where is Julia’s general registry located? Is there a list somewhere of what is in it? It’s a little hard for a user to know what to add if they don’t have a list on hand.
The status update shows
d. [SUGG] New paragraph?
e. [QUES] What is the “status update”? Or did you mean something like “status function” or “status report” or “current status” or maybe “project status”?
f. [QUES] What is a package UUID? I see this as a critical question. How is a UUID generated? By whom? Over what scope is it valid? Does it change when there is a new version of the package? Will it change inside my Julia installation once I “check it out”? Or is it fixed over all of time and space for a given package? Should I as a user of Julia be interested in the UUID for a package, or is it something technical?
The manifest status, in addition, includes the dependencies of explicitly added packages.
g. [QUES] How is it denoting this? I only see one package with a version and one without (obviously because it is a standard package). How do I know which are the dependencies of the explicitly added packages? I was expecting to see some kind of system of arrows to show dependencies. Perhaps a longer example would show this more clearly?
After a package is added to the project
h. [QUES] To the current environment? Or are we really only discussing projects?
i. [TYPO] an? https://en.wikipedia.org/wiki/At_sign
j. [QUES] How do I determine what versions are available?
that has not yet included
we will pull updates from that branch
l. [QUES] “Julia will pull updates…” ? Or does this refer to an example that was intended to be added later in the documentation?
m. [SUGG] Git has not been mentioned once, so far, in the documentation. This could be helpful in the introduction.
To go back to tracking the registry version of
Example , the command
free is used
n. [TYPO] Not sure if you consider the space after Example a typo or not.
o. [QUES] I have noticed that free seems to be used to always go back to the registry version. Isn’t this kinda strange given that someone might have checked out a specific branch, found a problem, decided to dev it and then wants to go back to the registry version of that branch? The way I read it right now, this will not happen. Or am I misunderstanding what free will do?
Adding unregistered packages
it can still be added by instead of the package name giving the URL to the repository to
p. [SUGG] "it can still be added by providing the repository URL instead of the package name to
just like for registered packages
q. [SUGG] “just as we did above for registered packages”
Adding a local package
r. [SUGG] An example would not be wasted. I realise there is a potential problem with Windows vs Linux paths.
when packages are updated
s. [SUGG] when packages are
and the packages updated
t. [TYPO(2)] and the package
By only using
add your Manifest will always have a “reproducible state”
u. [QUES] Is the branch I checked out also part of that state? I’m not sure if this contradicts previous information on the free command. The implication of this entire paragraph seems to be that if I don’t develop any packages I have a reproducible state. Or are branches also checked out as develop’d packages (or something equivalent)?
v. [QUES] We have learned that a manifest is where all the dependencies are stored. But what is Project.toml for?
w. [OTOP] Does the default environment have a Project.toml and Manifest.toml?
load packages at their current state at some path
x. [QUES] Not sure what this means. Do you just mean “at their current state of development”? I assume this means at their master branch?
y. [QUES] Does “at some path” in this sentence belong to “load packages” or “current state”?
Let’s try to
dev a registered package
z. [QUES] Can it also be used to dev unregistered packages, e.g. from a Git repo? If not, how do I do this? (It only just occurred to me right this moment after having this problem for some time that I could add it, then dev it. But is this really the intended way to do this?)
z1. [TYPO] Julia
z2. [QUES] Is importing supposed to mean something technical? Do you mean
adding? Probably not, given the next question… [Edit: oh sorry, I’m dumb. You mean when I do “import MyPkg” or “using MyPkg”. Would
importing be better here? Maybe not, as it might imply to some that import is a Pkg command.]
whatever local changes have been made to the files
z3. [QUES] I think this is intentionally written this way, but just want to check that this is in distinction to checking out local packages where just changing the files would not be sufficient.
It is therefore up to you to pull updates, change branches etc.
z4. [QUES] Does Julia offer commands for doing this? Or is it intended that this be done within the actual git repo itself?
the package manager we will simply
As a general rule, the package manager will never touch files that are tracking a path.
z6. [SUGG] This is almost a duplicate of the same statement a few lines up. I don’t understand why it is being emphasised here (again), if that is intended.
dev is used on a local path, that path to that package is recorded
z7. [QUES] Recorded where? In the manifest? I don’t completely understand the point that is being made here.
The path will be recorded relative to the project file
z8. [QUES] Wait! So dev is specific to a given project? This doesn’t equate with my experience of using it. [Doh! I think I’m getting confused about the default environment again, which is a project as far as this statement is concerned. So when I’m working on the Singular “project” (not meant in the technical Julia sense) in my default environment, but I dev’d AbstractAlgebra, the dev’d version will be used by Singular if Singular has it as a dependency. This is so terribly confusing when working on a collection of related, but nonetheless independent, packages - a “project” - which isn’t specified by a project file…]
without knowing the exact content of all the packages that are tracking a path
z9. [OTOP] Not an important point, but what does this mean? I had expected it to say “without knowing the contents of all the files at that path”. Why would only knowing the contents of packages tracking the path be sufficient?
if you add a dependency to a package that tracks a local path
z10. [QUES] Wouldn’t a project track a local path, instead of a package? I would expect the package to be at the local path. I unfortunately don’t understand this entire sentence.
z11. [NOTE] This is slightly confusing anyway. At this point I expect from the foregoing that packages don’t have dependencies, but projects do. But then projects can obviously depend on packages which are themselves projects (one presumes). Ours do, anyway. Or are you simply saying that if a package is dev’d and it is itself a project (because it has a Project.toml and Manifest.toml file) that changing either of these files manually in the dev’d location would cause the manifest of the parent project that depends on that package, to be out of sync? Or are you referring to the aforementioned “layering” of environments mentioned in a previous section?
To update sync the Manifest
z12. [QUES] What is an “update sync”. We have been telling users to run resolve for ages now not knowing what it actually does. It seems to fix a remarkable number of problems. But I just now note this is only mentioned in the developing packages section. I’m surprised it fixes issues for some of our users.
Packages can be removed from the current project by
z13. [QUES] Will this also remove dependencies of any package that is removed?
remove all packages that depends
z14. [TYPO] depend
the project is using
z15. [QUES] Not
using in the Julia technical sense, but “depends on”, presumably?
the latest compatible version
z16. [NOTE] This is a new concept not previously introduced. It could helpfully be introduced before this point.
all other packages direct dependencies
z17. [TYPO] packages’ ?? or do you mean package
z18. [QUES] I’m not actually sure what is intended by this sentence. Or is it just emphasising that no other packages in that project will be affected. It does seem to imply that dependencies of dependencies might change. But why? Also, what if a package was a direct dependency and an indirect dependency? Might seem like nitpicking, but honestly I’m not really sure what is meant here.
Packages that track a repository are not updated when a minor upgrade is done.
z19. [OTOP] Wow, that’s random!
Pinning a package
A pinned package will never be updated. A package can be pinned using
pin as for example
z20. [SUGG] To prevent a package from being updated, it can be pinned. This can be done using
Removing the pin is done using
z21. [OTOP] Really!? Another use for free?
unpin was not considered? I find this odd because every time I read about what free did previously, I assumed that was all it did. But it seems to have a lot of (hidden) consequences! I don’t think most people are going to notice this!
The tests for a package can be run using
z22. [TYPO] using the
z23. [QUES] What will this actually do? (I actually know, but I’m wondering if a new user would know where the tests for a project are located, or what Julia will look for in a project in order to run its tests.)
z24. [SUGG] Since new package developers will likely be reading this, it might be an opportunity to mention test sets with a link. I had not heard of them until someone asked me why we weren’t using them. I don’t have a strong opinion about including this here though. But if not here, where?
Building a package
The build step of a package is automatically run
z25. [QUES] Again, what explicitly does it do? Where does Julia look for the build script? (I know of course, but the new user would like to find it in the documentation.)
z26. [QUES] It would be really helpful to have a more precise statement, as we have noticed in the past that packages were being installed multiple times. What about if two dependencies of the same project depend on different versions of the same package? Or even just the same version? Does layering of projects factor in here?
Garbage collecting old, unused packages
Pkg keeps a log of all projects
z27. [QUES/OTOP] Where is the log? Can it be queried?
This is done with the
z28. [QUES] Is it ever done automatically? This is kind of what I think of when I think about a garbage collector.
z29. [TYPO] effects that
z30. [TYPO] “will not be touched” or “would not be altered”
The section on developing packages should explain what the dev --local command does.
I was really surprised the Developing Packages section did not tell me how to register a package or give the current guidelines on how to do this!
I was really surprised that the Developing Packages section did not explain how to issue a new version of a package!
I actually anticipated there would be a section on creating a new package on this page. Yes I see that I only have to glance over to the menu on the left to see there is a whole section on creating a package. I still believe a link to there from this page would be helpful. It’s not super obvious that the Managing Packages page wouldn’t contain all this information.