When testing a local package X, some issues appear while build-ing and precompile-ing.
The reason for that is the unregistered packages in the dependency tree.
The unregistered packages (Y and Z) are installed locally from their respective github repositories (at url_Y and url_Z), and they are functional (at least locally on my computer).
If I try to build package X that depends on the unregistered packages Y and Z using my Project.toml file:
name = "X"
uuid = "uuid_X"
version = "0.0.0"
[deps]
SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
Y = "uuid_Y"
Z = "uuid_Z"
[compat]
julia = "1"
[where]
Y = "url_Y"
Z = "url_Z"
Then, I get the following error message
Updating registry at `~/.julia/registries/General.toml`
ERROR: expected package `Y [tag_Y]` to be registered
and no Manifest.toml file is created.
So, to go around this issue, I comment out the unregistered packages under the [deps] and [where] tags.
Then I can build the package to create the Manisfet file, but of course I cannot precompile since there are missing dependencies.
Now, I add manually to the Manifest.toml the missing dependencies
and uncomment the commented lines in the Project.toml file.
Finally, running resolve rearranges the manifest and I can precompile package X (and test it locally).
I know it’s a very specific issue for when you want to use unregistered packages, but wouldn’t it be possible to add a functionality to build so that it can deal with unregistered packages? (or is it already a functionality and I’ve completely missed it? Not impossible at all)
As far as I understand it’s not possible to resolve unregistered packages with a project file alone.
I never heard of a where entry in the Project.toml and you should always ship/send/copy both project and manifest files when depending on unregistered package versions.
You don’t have to modify the manifest file manually yourself though, you can add unregistered versions either with Pkg.add or Pkg.develop (or their respective calls using the Pkg REPL mode) and the manifest file will be correctly generated for you.
You then have to simply copy it in the new location/computer you want to build the environment
Did you add the packages using a path rather than a name? Even for packages located directly as a subfolder of the current position you have to add specifiying the path with a dot.
So if you are in a folder containing the package folder Y, you should do add ./Y and not simply add Y
If you don’t specify a path it will always try to fetch a package with that name in the available registries.
If you try to add a local package just by its name I seem to remember the repl gives you a warning to tell you about this
Again, I didn’t mention that I had activate-ed the X-package project (activate /path/to/package/X/), which seems to make the difference.
So, I removed the packages Y and Z, and re-install them from the github repository.
I’ve updated the Project.toml (no more [where] tag)
name = "X"
uuid = "uuid_X"
version = "0.0.0"
[deps]
SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
Y = "uuid_Y"
Z = "uuid_Z"
[compat]
julia = "1"
Then, I locally dev the package X (dev /path/to/package/X/) and that’s it. I can build and precompile the package X.
I guess when I activate-ed project X, the unregistered packages could not be seen, maybe?
Know that if you activate a package environment (X in your case) you don’t have to dev X again.
When you are inside a package environment (inside as in you activated it) you can just do using X without having to add it. And if you are using Revise it will update changes in your source files of X