Version * does not match other versions

General Usage
1

I’m using Julia 1.5.3

Trying to run my tests locally, and I get this error about PyCall version conflicts.
My own package has a PyCall version dependency of * whereas some other package (not one of mine) has a PyCall version dependency of 1.18.0-1.18.5, 1.90.0, 1.91.0-1.91.4, 1.92.0-1.92.1

Any idea how I could get around this issue?

Pkg.Resolve.ResolverError("Unsatisfiable requirements detected for package PyCall [438e738f]:
 PyCall [438e738f] log:
  possible versions are: [1.18.0-1.18.5, 1.90.0, 1.91.0-1.91.4, 1.92.0-1.92.1] or uninstalled
  restricted to versions * by Snowflake [0bb4fc32], leaving only versions [1.18.0-1.18.5, 1.90.0, 1.91.0-1.91.4, 1.92.0-1.92.1]
  Snowflake [0bb4fc32] log:
      possible versions are: 0.1.0 or uninstalled
       Snowflake [0bb4fc32] is fixed to version 0.1.0
   restricted to versions 1.92.2 by an explicit requirement — no versions left", nothing)
2

I may be wrong but it seems like Snowflake fix the version to 1.92.2 but this version is not out yet? (or your registry is not updated) Because the list of all versions available ends at 1.92.1.

3

Snowflake’s Project.toml doesn’t list a version.

The Manifest.toml (which is automatically generated) pulled the latest version of whatever is in the registry, which is 1.92.2. This happened after running Pkg.update and Pkg.resolve.

Is there something I can specify in Manifest.toml to say that I don’t really care about the version?

4

Wait, the Snowflake.jl package is not yours and when downloaded using the registry it comes with a Manifest.toml? I am not sure this is regular behavior. I think packages should only have Project.toml files, Manifest.toml files in packages caused bugs in the past (I record seeing some threads on discourse about this).

5

Snowflake.jl is my own package, it’s not being downloaded, but when I Pkg.add a dependency, the Manifest.toml gets automatically updated. That’s where PyCall 1.92.2 came from.

6

If other package had PyCall restricted then it should appear in the log you posted. Are you doing this in an empty/new environment (what is the environment you dev/added your package)? This other package is a dependency of your, or has some reason to be in the same environment you are trying to do tests?

No, you can’t, because the purpose of the Manifest.toml is to register the exact versions used the last time the environment was instantiated. However, a Manifest.toml should always be valid, as it is generated with add commands and things are only added if they are valid. Can you remove the Manifest.toml and then do a Pkg.activate("."); Pkg.instantiate() in a Julia terminal inside the package folder (the one with the Project.toml)?

7

Are you doing this in an empty/new environment (what is the environment you dev / add ed your package)?

I am doing this in the module environment by running Pkg.test, the module environment contains both a Project.toml and an Manifest.toml that were automatically generated via add and develop commands.

Can you remove the Manifest.toml and then do a Pkg.activate("."); Pkg.instantiate() in a Julia terminal inside the package folder (the one with the Project.toml )?

That doesn’t work directly because of the dependencies on other local packages that are added via develop. I went back to the packages that had no internal dependencies. When I got to the second package (the first one that includes PyCall in its Project.toml), I got this:

(PyDB) pkg> develop /home/ubuntu/datascienceworkbench/lib/Modules-1.0/DBITypes
Path `/home/ubuntu/datascienceworkbench/lib/Modules-1.0/DBITypes` exists and looks like the correct package. Using existing path.
  Resolving package versions...
Updating `~/datascienceworkbench/lib/Modules-1.0/PyDB/Project.toml`
  [3aaf276a] + DBITypes v0.1.0 `~/datascienceworkbench/lib/Modules-1.0/DBITypes`
  [a93c6f00] + DataFrames v0.22.4
  [438e738f] + PyCall v1.92.2

This pulls in PyCall 1.92.2, which appears to be the latest version available.

8

1.92.2 indeed seems to be the latest version. Weird enough.

Could you provide the Project.toml files of both Snowflake.jl and the offending dependency, and also of the test environment (if exists)?

9

The problem is that I have no idea what the offending dependency is, and now after having run the above commands it passes, so whatever the offending dependency was has probably been upgraded.

2 Likes