While it’s nice to know that a fix is coming (thanks!), is there 1) any workaround in the meantime and 2) any idea when that might get merged?
This isn’t a fix, it’s a feature. The package manager works fine without it. All registered packages have their requirements correctly recorded and respected when you install them.
Not all packages are registered, and supposedly, things are moving away from having the big central registry,
so it’s rather important when people are dealing with their own set of packages (such as at a company not making their Julia code open source).
What is the recommended way of handling a large number of private packages, with their own set of dependencies and version requirements?
This isn’t a criticism, it already looks like Pkg3 may be able to handle this much better than Pkg2, I’d just like to understand the best practice for this use case.
Question: after some recent changes, it seems that even Test
needs to be specified as a dependency if I want to use it in pkg"test"
, is this correct?
Yes. Standard libraries need to be declared as dependencies when using them in a package, they also need now need to be declared as test dependencies if they are used when testing. The reason it worked before was due to a flaw and it means that e.g. moving stdlibs out of the julia repo was breaking.
Note that https://julialang.org/Pkg.jl/latest/ says to put something like the following in your Project.toml
[extras]
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"
[targets]
test = ["Test"]
Just to clarify, if I have more than one dependency in my tests, I should add them all under [extras] and then include them as a list of dependencies for the test target, e.g.
[extras]
Test = <uuid>
Dep1 = <uuid>
[targets]
test = ["Test","Dep1"]
When I tried this I got an error
ERROR: MethodError: no method matching haskey(::Array{String,1}, ::String)
Closest candidates are:
haskey(::Base.Iterators.Pairs, ::Any) at iterators.jl:246
haskey(::Dict, ::Any) at dict.jl:546
haskey(::Base.ImmutableDict, ::Any) at dict.jl:731
This is correct. The error is (likely) because your Julia version is too old.
Ok, this was on
julia> versioninfo()
Julia Version 0.7.0-beta2.0
Commit b145832402* (2018-07-13 19:54 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin14.5.0)
CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.0 (ORCJIT, broadwell)
I will wait for an updated version before trying again. Thanks everyone for the great work!
Could someone explain why it is necessary to declare the Test
extra dependencies in 2 stages? Is there some kind of point or advantage to separating out the [extras]
and [targets]
instead of having [test]
only?
See https://github.com/JuliaLang/Pkg.jl/pull/531#issuecomment-408032655 and https://github.com/JuliaLang/Pkg.jl/pull/531#issuecomment-408183823
Just wanted to add that this now works on
julia> versioninfo()
Julia Version 0.7.0-rc2.0
Commit 78540cba4c (2018-08-02 19:14 UTC)
Platform Info:
OS: macOS (x86_64-apple-darwin14.5.0)
CPU: Intel(R) Core(TM) i5-5257U CPU @ 2.70GHz
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-6.0.0 (ORCJIT, broadwell)
Thanks again!
In 1.0, can someone explain (or link the docs) how to handle Pkg3 automatically installing deprecated packages from Metadata?
Ex. Requests.jl isnt maintained anymore, hence deprecated, but if the user is unaware they are able to install it. One realises this later while trying to fix it as the program isnt working as before.
Ofcourse, you can rm
deprecated or unmaintained packages but it would be nicer if the PM were able to distinguish or tag packages for the specific julia version it (package) supports.
If this feature exists in Pkg3, then please link the docs (or a video/ blog). Thanks.