Do you have "General.tar.gz" in your `.julia/registries/`?

Community
,
1

Simple question:
Do you have “General.tar.gz” in your .julia/registries/ (or equivalent)?

You can check it, for example, by:

julia> readdir(joinpath(DEPOT_PATH[1], "registries"))
3-element Vector{String}:
 "General"
 "General.tar.gz" # HELLO❗
 "General.toml"
  • Yes, I have “General.tar.gz”.
  • No, I don’t have it.
0 voters

There is no need to think deeply about the intent of this question. Your julia is (probably) fine whether it exists or not.
I believe there is value in votes from those who do not understand the intent. So I am asking a somewhat roundabout question.
Also, the results are set to be displayed after the vote.

2

Although not directly related to this poll, the 2024 Julia User & Developer Survey is now open. Edit: closed.

3

I will not explicitly close the poll, but would like to conclude with my thoughts on the poll.

I think the uncompressed registries are still beneficial in several use cases and, in fact, it can be assumed that non-negligible numbers of people are using them given the results of the poll.

So, my argument is the following three points.

  1. Until a complete alternative to the uncompressed registry can be provided, the user experience with the uncompressed registry should avoid a major regression.
  2. Since many users use the compressed registry, if you encounter problems with the uncompressed registries (especially on nightly or pre-release), you should be proactive in reporting them.
  3. The guidance and prompts on the REPL to introduce the compressed registries would be worth providing for the next transition to the next LTS, which will probably occur in the near future.

Note that the compressed registries have been supported since Julia v1.7.

4

I’m curious about what are these several cases, because I can only think of problem they cause.

5

I can think of three use cases:

  1. They’re necessary for using registries that aren’t served by any package server.
  2. If you absolutely must have zero delay in what you can see in the registry then they’re also probably the only option, although the PKG_SERVER_REGISTRY_PREFERENCE=eager export is probably good enough 99% of the time.
  3. It’s also the easiest way to “checkout” a specific historical registry state and to pin a registry at that state.

I think 1 is unfixable—if something isn’t available via package server then it has to be available via git. 2 is probably already solved as well as it can be, although we could always work to reduce latency of publishing new registry hashes, but it’s already quite fast. 3 could definitely be improved, eg by allowing installation of a specific registry tree via the pkg REPL and also allowing pinning and unpinning a specific version.

1 Like