You can load a different copy of SHA without a UUID (or with a different UUID) since that will be considered to be a different package. You cannot load a different version of the same package with the same UUID if it’s already loaded without restarting; in the case of stdlib packages, since they’re built into the system image, that means you need to rebuild the system image.
Resurrecting this thread since there is a lot more discussion related to Pkg3 lately with the release of 0.7-alpha.
I’ve been working on updating some packages to comply with Pkg3 (I wrote this tool which I advertised elsewhere) and I think I foresee a pain point in the usage of the new Pkg. Since the Project.toml requires uuid’s for all the packages, it’s no longer possible to simply open up some file and specify all the packages you want to add. Granted, in many (most?) use cases one would just add packages one by one in the REPL, but there is something nice about being able to list them out all in one go in a simple text file, especially considering that each package now has its own environment, so you may potentially wind up repeating this procedure many times.
I see basically 3 ways of rectifying this:
- Allow optional, human writable fields to the
Project.tomlfacilitating the specification of all top level dependencies. (This doesn’t exist already, does it?) - Don’t deprecate
REQUIRE, but rather polish and formalize a tool analogous to mine above as a permanent part ofPkg. - Create a tool to analyze code and automatically generate a
Project.toml(defaulting to latest versions). This seems like it would be very hard to keep reliable and is probably a bad idea.
Option 1 seems like the best to me, though I do feel like maybe I’m failing to understand some feature of Pkg that obviates all this. As far as I was able to tell today, it is certainly up to users to make sure they specify all of their top level dependencies.
2 Likes
This is inherent to the design that a package is no longer uniquely defined by its name. If you say that you depend on “JSON”, I ask “which JSON”?. The uuid tells you that.
Regarding the tool, yes, generate will in not too long be able to run on an existing package and generate the dependencies, compatibility and the test dependencies.
8 Likes
Point taken, but I still feel like there is a loss of some form of valuable human readability as opposed to having the REQUIRE file. For example, if I look at a repo on github, I can no longer easily get a good idea of what the requirements are without REQUIRE. Maybe I’m making too much of this, or perhaps I’m just too used to the old way of doing things, but I feel there is some (perhaps small) value in being able to look at a repo and say “Oh, I have to have Compat \ge v"0.66.0”. Unless I’m missing something, you now have to have the package actually installed to infer this simple information. (Granted, there may be packages where the version constraints are much more complicated.)
Great!
1 Like
This information will be in the Project.toml file of the package.
Instead of
REQUIRE:
JSON
Compat
Foo
there will be
Project.toml
[deps]
JSON = "19e329df-c55f-496e-aa2e-59e4f9dde352"
Compat = "080d8da2-6b1c-4678-8906-8296444b2ae2"
Foo = "765ebfb0-3477-44aa-b801-5f525b7169b8"
I don’t really see what the problem is.
4 Likes
I am working a on a research project which requires me to basically catalog the universe of OSS. Throughout that project I have been getting familiar with many package manager systems (see Application level Dependency managers).
From this experience a few things I found were helpful and beneficial to implement for Julia were:
- Licence
- Citation (contributors and role - author, maintainer, etc.)
- Dependency charts (dependencies and packages that depend on it)
- Version history
- Statistics (downloads, open issues)
- Category (topics, tags, intended audience)
- Development Status (e.g., Planning, Pre-Alpha, Alpha, Beta, Production/Stable, Mature, Inactive)
- Project Link
- C.I.
Many of these are currently provided through PackageEvaluator.jl. However, it would be nice to incorporate the missing features within the new package manager.
PS: Some of these features are implemented at the repo with shields, but a systematic way to do this would be nice.
3 Likes
Yes, you could have a require like that, but you could also have
JSON 0.3.0
Compat 0.66.0
Foo
which gives minimum versions. Instead of the minimum versions you now have a hash that’s not human readable. I feel like the minimum versions are something people are going to want to see, that’s all.
1 Like
The hash has nothing to do with the minimum versions or versions at all. It is only to identify what package we are talking about.
The PR for compatibility is https://github.com/JuliaLang/Pkg.jl/pull/234 and it would look like:
[deps]
Example = "765ebfb0-3477-44aa-b801-5f525b7169b8"
[compatibility]
Example = "0.4"
2 Likes
Right, it identifies a specific version, correct? I think I understood what it was doing, I was just lamenting the loss of a human readable “compatibility” section.
Anyway, what you are proposing is all I was talking about. Glad to see it’s on the way!
No, not a specific version. A specific package.
The git-tree-sha in the Manifest is a specific version but that one is almost never read by a human.
1 Like
ok, this is getting confusing now. we said:
but then you say
So: what’s the difference between “which JSON”, a “specific version of JSON” and the “specific package called JSON”? I am asking because every now and then it’s very useful to be able to Pkg.pin(JSON,version) in case of a bug somewhere. Would I have to go and find a previous uuid of JSON to be able to do that with Pkg3? If I should just RTFM please tell me, I haven’t read anything except this thread. thanks!
This might help understand what’s going on:
1 Like
that link doesn’t work for me unfortunately. 
but that sounds like something I should know about in this context, right? https://docs.julialang.org/en/latest/stdlib/Pkg/#Developing-packages-1
This might help understand what’s going on:
https://docs.julialang.org/en/stable/manual/code-loading/index.html
I guess it’s the latest manual which you meant to link to:
https://docs.julialang.org/en/latest/manual/code-loading/index.html
Reading the manual is always helpful 
, but the short answer is that if you and I both create packages called JSON, how can a piece of code specify that it wants your package and not mine? Currently, we simply require that one of us change our name if we want to both register our packages, but that’s a big burden as package development becomes more decentralized. Pkg3 allows both of us to have our JSON packages in different registries, but the price is requiring the project file to be explicit.
1 Like
I’m on it! 
i never thought about the naming issue you mention. It may be a burden to have fewer and fewer available names, on the other hand the user/community will always have to figure out that my version of JSON is buggy and yours is excellent (say), and go find the right uuid. might as well call the packages “JSON” and “buggyJSON”? that’s how R rolls, AFAIK. but i’m sure you guys thought a lot about that, so it’s likely that I am missing something.
I should probably shut up and read the manual now. sorry.
One thing that was discussed back on GitHub some time ago (I’ll try to find it and link to it) was the idea of having things decentralized, and that maybe the Julia orgs could be a good way of handling that, so that if you can trust say, the BioJulia org, you can use their curated registry of packages useful for BioInformatics.
If the packages currently in stdlib end up being allowed to be in their own Git repositories, then JuliaLang could have the “ultra-trusted” registry for those packages.
I even had a crazy idea that maybe some blockchain ideas could be used, to say which registries are trusted (since that would allow that trust to be revoked, and would be decentralized).
Currently, how does one specify with Pkg3 (or “new” Pkg) the minimum version of some package?
I already have an issue with this, because the recent change from coalesce to something broke one of my packages (ModuleInterfaceTools), that pretty much every other package depends on, and on Travis on v0.7 they keep trying to pick up the broken v0.1.0 version instead of the fixed v0.1.2 version.
2 Likes
One waits for https://github.com/JuliaLang/Pkg.jl/pull/234 to be merged and put in the next nightly / alpha.
2 Likes