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

Support registries in gzipped tarballs #38

Closed

Conversation

danielmatz
Copy link

Starting with Julia 1.7, a registry can also be stored in a depot as a
gzipped tarball. This commit unpacks the tarball into a temporary
directory. This was the simplest way to support this new feature.

This implementation will unpack a fresh copy of the registry on every
call to reachable_registries. We could instead cache the temporary
directory for future calls.

There's an open PR for the Tar.jl package that will be of future
interest:

JuliaIO/Tar.jl#95

This would allow us to instead stream the individual files straight
out of the tarball, rather than having to unpack it into a temporary
location.

Starting with Julia 1.7, a registry can also be stored in a depot as a
gzipped tarball. This commit unpacks the tarball into a temporary
directory. This was the simplest way to support this new feature.

This implementation will unpack a fresh copy of the registry on every
call to `reachable_registries`. We could instead cache the temporary
directory for future calls.

There's an open PR for the Tar.jl package that will be of future
interest:

JuliaIO/Tar.jl#95

This would allow us to instead stream the individual files straight
out of the tarball, rather than having to unpack it into a temporary
location.
Copy link
Member

@giordano giordano left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a good approach. Pkg has its own API to analyse registries, whether they are gzipped or not, should use that instead

@danielmatz
Copy link
Author

I don't think this is a good approach. Pkg has its own API to analyse registries, whether they are gzipped or not, should use that instead

Yes, I see Pkg has a Pkg.Registry.reachable_registries function as of Julia 1.7.

Are you proposing that this package require Julia 1.7 or newer and remove its duplicate implementations of the registry-related code?

Or should I detect the Julia version and use the Pkg API if available, and otherwise fall back to the existing registry code in PkgDeps, which would not support tarballs?

@giordano
Copy link
Member

giordano commented Jun 1, 2022

I guess that's a question for @mattBrzezinski. The question boils down to whether supporting julia v1.6 is important, or we can drop it and move to v1.7+ only. We have a similar situation in PackageAnalyzer, there I'd be ok with dropping v1.6 and moving to v1.7+ only.

@danielmatz
Copy link
Author

OK, I made a new PR with the approach of requiring Julia 1.7. See #39.

@mattBrzezinski
Copy link
Member

I guess that's a question for @mattBrzezinski. The question boils down to whether supporting julia v1.6 is important, or we can drop it and move to v1.7+ only. We have a similar situation in PackageAnalyzer, there I'd be ok with dropping v1.6 and moving to v1.7+ only.

I would prefer to maintain support for LTS versions of Julia.

@danielmatz
Copy link
Author

Well, the LTS version of Julia won't create gzipped tarballs. I bumped the julia compat entry in my other PR. So, I suppose we could release v0.7 of this package, which would require Julia 1.7, while maintaining v0.6 for the LTS version of Julia?

Alternatively, I could rework my PR so that it uses the Pkg API for Julia 1.7+, but gracefully falls back to your existing code for the LTS.

@mattBrzezinski
Copy link
Member

We could instead do something nifty like this to handle the differences between versions!

@danielmatz
Copy link
Author

OK, I took a stab at it in my other PR.

@danielmatz
Copy link
Author

Closing this in favor of #42.

@danielmatz danielmatz closed this Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants