I’ve created folder
test with the following
[deps] QuantumControlBase = "f10a33bc-5a64-497c-be7b-6f86b4f0c2aa" GRAPELinesearchAnalysis = "290eba36-e2d8-4488-81b6-f66cc44f2186" [compat] julia = "1.6"
There is no
Manifest.toml in the
I have a checkout of both QuantumControlBase and GRAPELinesearchAnalysis in sibling folders of
QuantumControlBase is in the standard registry while
GRAPELinesearchAnalysis is unregistered.
GRAPELinesearchAnalysis depends on
QuantumControlBase (and other registered packages in JuliaQuantumControl), but not vice versa. I want to start a REPL using both packages in dev-mode based on the local checkout I have. Here is what I get when I try to dev-install the packages:
goerz@ophelia master:~/JuliaQuantumControl> julia --project=test _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.6.1 (2021-04-23) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> import Pkg julia> Pkg.develop(path="./QuantumControlBase.jl/") Path `./QuantumControlBase.jl/` exists and looks like the correct package. Using existing path. Resolving package versions... ERROR: expected package `GRAPELinesearchAnalysis [290eba36]` to be registered
I’ve run into this same problem before when trying to develop the various packages in the JuliaQuantumControl org. All of these should be tested against each other’s
master or uncommitted versions, both locally and on CI (see the setup in the various projects’ Makefile and
CI.yml). I haven’t been able to make this work at all while any of the packages were unregistered.
So far, I’ve worked around that by registering packages a bit “pre-maturely” as
0.0.1 versions, but for
GRAPELinesearchAnalysis I don’t think I even want that to be registered: it’s just a debugging tool, plus the 3-day wait/review period for a new package will be a hassle for something that I want to quickly push out to a collaborator.
I’m just about ready to explore setting up my own registry, which would probably get around this problem, but is there really no way to instantiate an environment with dev-versions of unregistered packages?