Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reachable_registries doesn't find the General registry #37

Open
danielmatz opened this issue May 25, 2022 · 13 comments · May be fixed by #42
Open

reachable_registries doesn't find the General registry #37

danielmatz opened this issue May 25, 2022 · 13 comments · May be fixed by #42

Comments

@danielmatz
Copy link

danielmatz commented May 25, 2022

On my Mac, everything works fine. But on a Linux cluster at work, I'm having an issue with reachable_registries.

Julia knows about both the General registry and our private registry.

(jl_SqSi8q) pkg> registry status
Registry Status
 [09fcaf40] EG
 [23338594] General

But reachable_registries only returns our private registry.

julia> length(reachable_registries())
1
julia> first(reachable_registries()).name
"EG"

I've tried removing and re-adding both registries, without success.

I'm on Julia 1.7.2.

julia> versioninfo()
Julia Version 1.7.2
Commit bf53498635 (2022-02-06 15:21 UTC)
Platform Info:
  OS: Linux (x86_64-pc-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E5-2690 v4 @ 2.60GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-12.0.1 (ORCJIT, broadwell)
@mattBrzezinski
Copy link
Member

On your Mac are you using the same version of Julia? I suspect something is different between 1.6 and 1.7 here causing the issue.

@danielmatz
Copy link
Author

Yes, I'm also using 1.7.2 on my Mac.

@mattBrzezinski
Copy link
Member

Yes, I'm also using 1.7.2 on my Mac.

Hmm interesting. Okay, the way the code works is by default looking at Base.DEPOT_PATH. From there it looks at the sub-directory of all these dirs for Registries to try and get the names of all those available.

If you start up a REPL you can mimic this by doing...

julia> depots = Base.DEPOT_PATH
3-element Vector{String}:
 "/Users/mattbr/.julia"
 "/Applications/Julia-1.7.app/Contents/Resources/julia/local/share/julia"
 "/Applications/Julia-1.7.app/Contents/Resources/julia/share/julia"

julia> for d in depots
         try
           println(readdir(joinpath(d, "Registries")))
         catch
           println("DNE $d")
         end
       end
[".DS_Store", "General", "Invenia"]
DNE /Applications/Julia-1.7.app/Contents/Resources/julia/local/share/julia
DNE /Applications/Julia-1.7.app/Contents/Resources/julia/share/julia

Might give some insight into what's going on

@danielmatz
Copy link
Author

julia> depots = Base.DEPOT_PATH
3-element Vector{String}:
 "/home/dmatz/.julia"
 "/software/x86_64/julia/julia-1.7.2/local/share/julia"
 "/software/x86_64/julia/julia-1.7.2/share/julia"

julia> for d in depots
                try
                  println(readdir(joinpath(d, "Registries")))
                catch
                  println("DNE $d")
                end
              end
DNE /home/dmatz/.julia
DNE /software/x86_64/julia/julia-1.7.2/local/share/julia
DNE /software/x86_64/julia/julia-1.7.2/share/julia

I think you meant lowercase "registries", but macOS didn't mind the capital R. If I use lowercase on Linux, I get:

julia> for d in depots
                try
                  println(readdir(joinpath(d, "registries")))
                catch
                  println("DNE $d")
                end
              end
["EG", "General.tar.gz", "General.toml"]
DNE /software/x86_64/julia/julia-1.7.2/local/share/julia
DNE /software/x86_64/julia/julia-1.7.2/share/julia

Which is interesting... my Mac result including a "General" directory, but Linux just has a tarball. Is that OK?

@mattBrzezinski
Copy link
Member

Hmmm I'm not sure why there's a tarball on Linux, I just asked a co-worker who uses Linux to run this and they have directories instead.

@danielmatz
Copy link
Author

When I do registry rm General, that tarball goes away. And when I do registry add General, it comes back... Did the way registries get downloaded change in a recent Julia release, and you and your coworkers have a directory around from an earlier version?

And I'm guessing that reachable_registries looks for directories only, not tarballs?

@mattBrzezinski
Copy link
Member

When I do registry rm General, that tarball goes away. And when I do registry add General, it comes back... Did the way registries get downloaded change in a recent Julia release, and you and your coworkers have a directory around from an earlier version?

And I'm guessing that reachable_registries looks for directories only, not tarballs?

I'm not sure what's changed w/ Julia specifically to this, I don't pay too much attention to releases. My coworker has 1.6 installed, and also installed 1.7 for this test, both times they were directories.

Yes, reachable_registeries() only looks for directories here.

@danielmatz
Copy link
Author

Ah hah, check this out in the 1.7 release notes:

Registries downloaded from the Pkg Server (not git) are no longer uncompressed into files but instead read directly from the compressed tarball into memory. This improves performance on filesystems which do not handle a large number of files well. To turn this feature off, set the environment variable JULIA_PKG_UNPACK_REGISTRY=true.

@mattBrzezinski
Copy link
Member

Ah there we go! We'll need to update the README to include that, we need the information from the Registry.toml file to get all the information so it'll need to be unpacked.

@danielmatz
Copy link
Author

You can use Tar.jl and CodecZlib.jl to extract Registry.toml:

julia> open(".julia/registries/General.tar.gz") do io
          Tar.extract(GzipDecompressorStream(io)) do header
               header.path == "Registry.toml"
           end
       end
"/var/folders/9w/2h0b6sxs1f52vsyjfvczy58462lf_p/T/jl_LPiI4R"

There may also be a way to extract it into an IOBuffer instead of a temp file...

@mattBrzezinski
Copy link
Member

You can use Tar.jl and CodecZlib.jl to extract Registry.toml:

julia> open(".julia/registries/General.tar.gz") do io
          Tar.extract(GzipDecompressorStream(io)) do header
               header.path == "Registry.toml"
           end
       end
"/var/folders/9w/2h0b6sxs1f52vsyjfvczy58462lf_p/T/jl_LPiI4R"

There may also be a way to extract it into an IOBuffer instead of a temp file...

Ah yeah, we can definitely make these changes! I'm quite busy with other work, if you'd like to make the PR I can do code review on it and get it through! If not, I can make these changes at some point.

@danielmatz
Copy link
Author

Sure, I'll take a shot at it.

@danielmatz
Copy link
Author

See #38

danielmatz added a commit to danielmatz/PkgDeps.jl that referenced this issue Jun 1, 2022
As of Julia 1.7, Pkg.Registry provides some of the capability that had
been implemented in this package. This commit makes this package's
`reachable_registries` a simple wrapper around
`Pkg.Registry.reachable_registries` and removes the `RegistryInstance`
and `PkgEntry` types in favor of the types of the same name in
Pkg.Registry.

The largest change is that this package's version of
`RegistryInstance` stored a dictionary mapping package names to
`PkgEntry`s, but Pkg.Registry's version has a dictionary mapping
`UUID`s to `PkgEntry`s.

A benefit of using the `Pkg.Registry` API is that it already supports
both uncompressed registries as well as registries stored in
compressed tarballs. Thus, this fixes JuliaEcosystem#37.
danielmatz added a commit to danielmatz/PkgDeps.jl that referenced this issue Jun 22, 2022
As of Julia 1.7, Pkg.Registry provides some of the same capability
implemented in this package. When `VERSION` is at least v1.7, we use
`Pkg.Registry.reachable_registries`, `Pkg.Registry.RegistryInstance`,
and `Pkg.Registry.PkgEntry` instead of the custom versions implemented
in this package. For lower version numbers, we use the custom versions
implemented in this package.

The largest change when using the new capabilities in Pkg.Registry is
that this package's version of `RegistryInstance` stored a dictionary
mapping package names to `PkgEntry`s, but Pkg.Registry's version has a
dictionary mapping `UUID`s to `PkgEntry`s.

A benefit of using the `Pkg.Registry` API is that it already supports
both uncompressed registries as well as registries stored in
compressed tarballs. Thus, this fixes JuliaEcosystem#37.
danielmatz added a commit to danielmatz/PkgDeps.jl that referenced this issue Jun 23, 2022
As of Julia 1.7, Pkg.Registry provides some of the same capability
implemented in this package. When `VERSION` is at least v1.7, we use
`Pkg.Registry.reachable_registries`, `Pkg.Registry.RegistryInstance`,
and `Pkg.Registry.PkgEntry` instead of the custom versions implemented
in this package. For lower version numbers, we use the custom versions
implemented in this package.

The largest change when using the new capabilities in Pkg.Registry is
that this package's version of `RegistryInstance` stored a dictionary
mapping package names to `PkgEntry`s, but Pkg.Registry's version has a
dictionary mapping `UUID`s to `PkgEntry`s.

A benefit of using the `Pkg.Registry` API is that it already supports
both uncompressed registries as well as registries stored in
compressed tarballs. Thus, this fixes JuliaEcosystem#37.
danielmatz added a commit to danielmatz/PkgDeps.jl that referenced this issue Dec 20, 2022
The Pkg API often changes with each Julia release. Some of the
capability of Pkg had been duplicated in this package, but it lacked
some of the new capabilities of Pkg. With this change, we now leverage
RegistryInstances, which makes it easier for us to support multiple
versions of Julia.

There are a few differences between the old implementation that was in
this package and the implementation provided by RegistryInstances:
- The old `RegistryInstance` had a `pkgs` field containing a
dictionary mapping package names to `PkgEntry`s. The RegistryInstances
version of `RegistryInstance` has a `pkgs` field, too, but it is a
dictionary mapping `UUID`s to `PkgEntry`s.
- The old `PkgEntry` had a `repo` field. The RegistryInstances
version does not. Instead, it has a lazily initialized `info` field,
which should be accessed using `RegistryInstances.registry_info`.

Another benefit of using RegistryInstances is that it supports both
uncompressed registries as well as registries stored in compressed
tarballs. Thus, this fixes JuliaEcosystem#37.
@danielmatz danielmatz linked a pull request Dec 20, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants