Developed package "shadows" dependency package

General Usage
1

I’m not sure how to formulate this question/issue, I try to be as straightforward as possible.
So I have two packages developed by myself (both are public, hosted on github). I started developing PackageA and at some point made a tag, let’s call it tagofA (then continued developing). Then I started developing PackageB which has PackageA as dependency, and I added the version of the tag (tagofA) as the version of the dependency. My issue is, that now, that both packages are ]dev-ed, and the tag is added as dependency, it seems, that using PackageB loads the dev-ed version of PackageA.

So I,

  1. ]dev-ed PackageA
  2. ]dev-ed PackageB
  3. added PackageA#tagofA as dependency to PackageB
  4. and using PackageB loads the ]dev-ed version of PackageA insted of the tagofA.

Both packaged are ]dev-ed in the main Julia 1.3. environment, on Windows10. I skimmed through the documentation of Pkg, searching for the develop keyword, but did not find anything useful.
Is this the expected behavior or is it a bug? Or am I missing something?

2

How are you specifying the version of PackageA in PackageB? The reason I’m asking is that if you specify just the plain version number, all versions after that that aren’t supposed to be breaking are allowed, e.g. when you specify 1.0.0, 1.0.2 or 1.3.2 are allowed as well. This is explained pretty well in the Pkg docs here:
https://julialang.github.io/Pkg.jl/v1/compatibility/
If you don’t want that, you can restrict the allowed versions further either with ~1.0.0 or, even more restrictive =1.0.0.
Edit:
This would go under the [compat] section in your Project.toml file of ProjectB. If you only added the dependency in the pkg> REPL, then you probably don’t have a compat entry and need to add it.

1 Like
3

You don’t add a version of a package as a dependency, only the package itself. The version you get is what the resolver (the thing that figures out versions) gives you. The version information is stored in the Manifest.toml file. The manifest file of dependent packages is not used, only the manifest file of the current project is used. Therefore, since you have PackageA developed in your current project, that is also the version of PackageA that will be loaded.

Also, note that there will ever only be one version of a package loaded in a given Julia session.

3 Likes
4

I thought I specified by addig the package to the PackageB environment by ]add PackageA#tagofA. As the version I want to use is tagged with version number, but with a name, I don’t think I can specify it with a [compat] entry.

5

Thank you, this make sense!

6

This makes sense, but was not immediately obvious to me. I had a package (Package) that in it’s manifest declared the use of a fork of a dependency (Dependency). A project (project) using Package then will have to also specify the fork of Dependency in its manifest file, otherwise the non fork will be installed when doing instantiate -m on the project manifest.
(related to our brief discussion we forgot about on slack the other day, Kristoffer)

Question: If I in Package want to enforce the fork of Dependency being used, is the correct way forward to pin Dependency in Package’s environment?

7

I don’t really understand what “in ‘Package’” means. The version/fork of ‘Dependency’ that will be used is the one in the manifest for your current active project (the one showed by ‘status -m’)

8

I mean that Package is only compatible with the fork, so any project using Package must get the fork installed. If I in the package environment add the fork, this is not enough, as projects adding the package still get the non fork dependency in their Manifest.

9

Pkg doesn’t know about forks. It nows about packages (identified by UUID) and versions. So in this case, changing the UUID for the fork and depending on that should work.

1 Like