Project that depends on unreleased packages: Unsatisfiable requirements

I’m trying to figure out how to instantiate a project that depends on unreleased but registered packages with properly set-up version numbers and compatibility requirements in Project.toml (for use on CI; preparing for JuliaRegistrator). For example:

$ git clone
$ cd CUDAnative.jl

# directly instantiating doesn't work,
# because CUDAnative depends on an unreleased CUDAdrv.

$ julia --project -e 'using Pkg; Pkg.add([PackageSpec(name=pkg; rev="master")
                                          for pkg in ("CuArrays", "CUDAdrv")])'
   Cloning default registries into `~/.julia`
   Cloning registry from ""
     Added registry `General` to `~/.julia/registries/General`
   Cloning git-repo ``
  Updating git-repo ``
   Cloning git-repo ``
  Updating git-repo ``
 Resolving package versions...
ERROR: Unsatisfiable requirements detected for package CUDAdrv [c5f51814]:
 CUDAdrv [c5f51814] log:
 ├─possible versions are: 2.1.0 or uninstalled
 ├─restricted to versions 2.0.0-2 by CuArrays [3a865a2d], leaving only versions 2.1.0
 │ └─CuArrays [3a865a2d] log:
 │   ├─possible versions are: 1.0.2 or uninstalled
 │   └─CuArrays [3a865a2d] is fixed to version 1.0.2
 ├─CUDAdrv [c5f51814] is fixed to version 2.1.0
 └─found to have no compatible versions left with CUDAnative [be33ccc6] 
   └─CUDAnative [be33ccc6] log:
     ├─possible versions are: [0.1.0-0.1.3, 0.2.0, 0.3.0-0.3.1, 0.4.0-0.4.2, 0.5.0-0.5.5, 0.6.0-0.6.3, 0.7.0, 0.8.0-0.8.10, 0.9.0-0.9.1, 0.10.0-0.10.1, 1.0.0-1.0.1, 2.0.0-2.0.1] or uninstalled
     └─restricted to versions 2.0.0-2 by CuArrays [3a865a2d], leaving only versions 2.0.0-2.0.1
       └─CuArrays [3a865a2d] log: see above

For some reason, the resolver isn’t happy and I don’t understand why. Version requirements seem to be OK, this is (the relevant pieces of) what’s in the package’s Project.toml files on the master branches:

$ cat CUDAdrv/Project.toml
version = "2.1.0"

$ cat CUDAnative/Project.toml
version = "2.1.0"
CUDAdrv = "2.1"

$ cat CuArrays/Project.toml
version = "1.0.2"
CUDAnative = "2.0"
CUDAdrv = "2.0"

Neither CUDAnative or CUDAdrv 2.1 have been released, but the master branches provide those versions which should be compatible with CuArrays. It works when only adding CUDAdrv#master, so it must have something to do with CuArrays’ compatibility requirements.

Adding CUDAnative to #master as well seems to make it go through. Not sure why yet.

Hmm, it feels like this should work, but it looks like it doesn’t when you’re working in the project of one of the dependencies of a package you’re trying to add. I typically use a separate project, as in

julia --project=. #in some directory


] add CUDAdrv#master
] add
] add CuArrays#master

But I think this is a valid use case that should be supported.

What do you mean exactly? I interpreted it as trying to add CUDAnative#master as a dependency to itself, which fails (as expected):

(CUDAnative) pkg> add CUDAnative#master
  Updating git-repo `ssh://`
ERROR: Cannot add package with the same name or uuid as the project

I just meant in a “naked” environment, adding CUDAnative to the list in the first post. Perhaps I misunderstood something.

In the OP, CUDANative doesn’t actually appear as a dependency in the active project, it is the active project.

Yeah, adding CUDAnative#master would check-out the master branch of package, while this is intended to test whatever branch has been checked-out in that folder (again, for CI purposes).

A workaround I’ve found (but complicates other commands) is to add the current directory:

$ julia -e 'using Pkg; Pkg.add([PackageSpec(path=pwd());
                                [PackageSpec(name=pkg; rev="master")
                                 for pkg in ("CuArrays", "CUDAdrv")]])'

The problem with this is that you can’t just Pkg.test() anymore, which fails with cannot test an unnamed project (so the CI user would need to provide the name of the project under test).