V1.6 Package manager issue

The new version v1.6 creates strange problems with my packages which I can’t fix.

For example:

(@v1.6) pkg> st JLD2
      Status `~/.julia/environments/v1.6/Project.toml`
  [033835bb] JLD2 v0.3.3

(@v1.6) pkg> up
ERROR: Unsatisfiable requirements detected for package JLD2 [033835bb]:
 JLD2 [033835bb] log:
 ├─JLD2 [033835bb] has no known versions!
 └─restricted to versions 0.2-0.4 by NMFk [e40cd9e2] — no versions left
   └─NMFk [e40cd9e2] log:
     ├─possible versions are: 1.1.21 or uninstalled
     └─NMFk [e40cd9e2] is fixed to version 1.1.21

I do not understand why it says no versions left when the existing version of JLD2 0.3.3 is within the bounds (0.2-0.4).

resolve and rm JLD2 does not help.

What should I do to fix it?! I do not want to delete my environment and start from scratch.

Just a guess but Inhad to delete my Manifest before resolving.

My errors seemed similar?

Could it be some ill interaction of Julia 1.5 and 1.6?

Delete the registry and add it back:

]registry rm General
registry add General

I agree that 1.5 and 1.6 interplays might be causing it

I had something related. I kept deleting packages and each time a new one had a complaint. I then deleted the registry and added it back. Something similar to what @giordano illustrates. I found my solution on StackOverflow

1 Like

I find that the cleanest solution is to simply delete the complete Julia depot and start from scratch.

2 Likes

Why the transition from 1.5 to 1.6 should be that complicated?!

I believe that is because there are breaking changes in Pkg. And I must say definitely worth it: updating the registry and the overall experience are much improved in 1.6!

I agree. but it should be 2.0 not 1.6

Well, remember that Pkg is only a package, not the language itself.

There are no breaking changes in Pkg, not sure what you’re talking about. The transition shouldn’t be that complicated. Deleting the entire .julia depot is never a good idea and I personally don’t recommend it. The issue with the registry is more likely related to an issue during a download which caused the registry to be corrupted. It could have happened at any point.

2 Likes

Well, if there is no compatibility issue, how come I can’t use the same .toml files with 1.5 and 1.6?

I delete the depot any time I feel like it, and I’ve never had any trouble. Edit: If you develop packages IN the DEPOT, then do not delete the depot without making sure your work is not lost.

2 Likes

The only general incompatibility is for manifests: a manifest generated for Julia v1.x cannot, in general, be used with Julia v1.y, with x != y. That’s it. This is the reason why the global environments are stored in different directory for different minor versions and it has always been the case in the v1 series.

Monty reported an issue with the registry, which doesn’t have anything to do with manifests.

You’re free to do whatever you feel like, but please don’t recommend to people to do operations that can cause data loss, albeit limited to Julia. Especially when the problem is limited to the registry: there is no point in deleting all packages when it’s possible to reinstall the registry with a single command without touching anything else. Developed packages are git repositories under .julia: it’s not fun to lose your local work because someone suggested you to delete the entire .julia directory unnecessarily.

4 Likes

The manifests: I thought that the reason the manifests couldn’t be used with different versions was because Pkg changed and hence couldn’t work with the old toml?

Deleting the depot: True, it depends on how one develops. I never develop anything in the depot. It is not convenient.

Not at all. Manifests can be incompatible for different reasons:

  1. packages can and do have different compatibilities with different minor versions: a version of package MyPackage available for Julia v1.5 may not be available for Julia v1.6, or the other way around. I’m sure you know this very well since you maintain packages with this property. In large manifests the probability that a situation like this happens is non-negligible.
  2. Julia itself may have different standard libraries between two different minor versions. Also standard libraries are recorded in manifests, so if you try to load a manifest which has standard libraries unknown to the current version of Julia, something bad happens. It is the case that a few standard libraries were introduced in Julia v1.6, so using manifests generated with Julia v1.6 may not work with Julia v1.5-.

I’m glad you found a more convenient way to develop your packages, but other people may have different workflows. Suggesting them to delete everything without any warning about the possible consequences is very bad

6 Likes

Looks like indeed something is messed up with the regsitry. Deleting it and adding it back like @giordano said is probably the best. All the discussion about manifest seems completely irrelevant.

1 Like

Hmm. I suspect that is not the whole story. When I try to use the manifest from 1.6 with Julia 1.5.4 I get this error:

(FinEtoolsAcoustics) pkg> instantiate
ERROR: AssertionError: sourcepath !== nothing
Stacktrace:
 [1] is_package_downloaded at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\Operations.jl:1670 [inlined]
 [2] #12 at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\Operations.jl:113 [inlined]
 [3] _all(::Pkg.Operations.var"#12#13"{Pkg.Types.Context}, ::Array{Pkg.Types.PackageSpec,1}, ::Colon) at .\reduce.jl:828
 [4] #all#638 at .\reducedim.jl:735 [inlined]
 [5] all at .\reducedim.jl:735 [inlined]
 [6] is_instantiated at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\Operations.jl:113 [inlined]
 [7] instantiate(::Pkg.Types.Context; manifest::Nothing, update_registry::Bool, verbose::Bool, platform::Pkg.BinaryPlatforms.Windows, kwargs::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\API.jl:828
 [8] instantiate(::Pkg.Types.Context) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\API.jl:795
 [9] #instantiate#169 at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\API.jl:791 [inlined]
 [10] instantiate() at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\API.jl:791
 [11] do_cmd!(::Pkg.REPLMode.Command, ::REPL.LineEditREPL) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\REPLMode\REPLMode.jl:401
 [12] do_cmd(::REPL.LineEditREPL, ::String; do_rethrow::Bool) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\REPLMode\REPLMode.jl:382
 [13] do_cmd at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\REPLMode\REPLMode.jl:377 [inlined]
 [14] (::Pkg.REPLMode.var"#24#27"{REPL.LineEditREPL,REPL.LineEdit.Prompt})(::REPL.LineEdit.MIState, ::Base.GenericIOBuffer{Array{UInt8,1}}, ::Bool) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\Pkg\src\REPLMode\REPLMode.jl:546
 [15] #invokelatest#1 at .\essentials.jl:710 [inlined]
 [16] invokelatest at .\essentials.jl:709 [inlined]
 [17] run_interface(::REPL.Terminals.TextTerminal, ::REPL.LineEdit.ModalInterface, ::REPL.LineEdit.MIState) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\REPL\src\LineEdit.jl:2355
 [18] run_frontend(::REPL.LineEditREPL, ::REPL.REPLBackendRef) at C:\buildbot\worker\package_win64\build\usr\share\julia\stdlib\v1.5\REPL\src\REPL.jl:1144
 [19] (::REPL.var"#38#42"{REPL.LineEditREPL,REPL.REPLBackendRef})() at .\task.jl:356

(FinEtoolsAcoustics) pkg>

I believe this is due to point 2: different standard libraries

Right, in particular Pkg, I believe.