Pkg servers: The eager registry flavor is significantly lagging behind the General registry's master branch
#120562
Comments
|
If you need the latest package version right now, you can try switching to the "eager" flavor of the registry: ENV["JULIA_PKG_SERVER_REGISTRY_PREFERENCE"] = "eager"
import Pkg
Pkg.Registry.update()Try that out, and if you can't get the latest package version when you're using the eager registry, let me know, and I'll reopen this issue. |
|
I tried running those commands but I still can't get the newest version to download. However, I've noticed that one of those other packages I tested before (Enzyme.jl specifically) that released a longer time ago seems to have finally propagated. In this case I'm expecting version julia> ENV["JULIA_PKG_SERVER_REGISTRY_PREFERENCE"] = "eager"
"eager"
julia> import Pkg
julia> Pkg.Registry.update()
Updating registry at `~/.julia/registries/General.toml`
(@v1.11) pkg> add CombinatorialSpaces
Resolving package versions...
Updating `~/.julia/environments/v1.11/Project.toml`
[b1c52339] + CombinatorialSpaces v0.6.7
...
(@v1.11) pkg> add Enzyme
Resolving package versions...
Installed Enzyme ─ v0.13.18
Updating `~/.julia/environments/v1.11/Project.toml`
[7da242da] + Enzyme v0.13.18 |
|
If this is simply a case of "sit and wait", that's not too much of a problem for me. However, I just wanted to point this out in case there was some kind of unintended slowdown/blockage in the registry. |
|
Well, the goal of the eager registry is to never have that delay. So this may be a bug in the Pkg server. |
|
Same issue on my side, been waiting 12 hours, also using "Eager" |
DilumAluthge
changed the title
eager)
|
I am able to reproduce this in a clean setup with Julia 1.11.1. Here are the steps to reproduce. First, run the following commands in Bash: unset JULIA_NUM_THREADS
unset JULIA_PROJECT
unset JULIA_LOAD_PATH
unset JULIA_PKG_SERVER
export JULIA_DEPOT_PATH="$(mktemp -d)"
julia --startup-file=no --history-file=noNow, inside Julia, run the following commands: ENV["JULIA_PKG_PRECOMPILE_AUTO"] = "0"
ENV["JULIA_PKG_SERVER_REGISTRY_PREFERENCE"] = "eager"
import Pkg
Pkg.Registry.add()
Pkg.Registry.update()
Pkg.add("CombinatorialSpaces")
Pkg.status()
Pkg.add(; name = "CombinatorialSpaces", version = "0.6.8")Here is the output that I get: $ unset JULIA_NUM_THREADS
$ unset JULIA_PROJECT
$ unset JULIA_LOAD_PATH
$ unset JULIA_PKG_SERVER
$ export JULIA_DEPOT_PATH="$(mktemp -d)"
$ julia --startup-file=no --history-file=no
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.11.1 (2024-10-16)
_/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |
julia> ENV["JULIA_PKG_PRECOMPILE_AUTO"] = "0"
"0"
julia> ENV["JULIA_PKG_SERVER_REGISTRY_PREFERENCE"] = "eager"
"eager"
julia> import Pkg
[ Info: Precompiling Pkg [44cfe95a-1eb2-52ea-b672-e2afdf69b78f]
julia> Pkg.Registry.add()
Installing known registries into `/var/folders/f4/dd0zhsvj5099rqhl7v7wjq580000gq/T/tmp.wOmv6COwdI`
Added `General` registry to /tmpdepot/registries
true
julia> Pkg.Registry.update()
Updating registry at `/tmpdepot/registries/General.toml`
julia> Pkg.add("CombinatorialSpaces")
Updating registry at `/tmpdepot/registries/General.toml`
Resolving package versions...
...
Updating `/private/tmpdepot/environments/v1.11/Project.toml`
[b1c52339] + CombinatorialSpaces v0.6.7
Updating `/private/tmpdepot/environments/v1.11/Manifest.toml`
...
julia> Pkg.status()
Status `/private/tmpdepot/environments/v1.11/Project.toml`
[b1c52339] CombinatorialSpaces v0.6.7
julia> Pkg.add(; name = "CombinatorialSpaces", version = "0.6.8")
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package CombinatorialSpaces [b1c52339]:
CombinatorialSpaces [b1c52339] log:
├─possible versions are: 0.1.0 - 0.6.7 or uninstalled
├─restricted to versions * by project [5aa5a18c], leaving only versions: 0.1.0 - 0.6.7
│ └─project [5aa5a18c] log:
│ ├─possible versions are: 0.0.0 or uninstalled
│ └─project [5aa5a18c] is fixed to version 0.0.0
└─restricted to versions 0.6.8 by an explicit requirement — no versions left
Stacktrace:
...However, looking at the registry, I see that CombinatorialSpaces v0.6.8 should be available when using the General/C/CombinatorialSpaces/Versions.toml Lines 64 to 65 in 4efa4f5 |
|
I took a look at which commits In hyperlink format: |
|
So currently, |
DilumAluthge
changed the title
eager)eager registry flavor is significantly lagging behind the master branch
|
I'm also experiencing this trying to use InfiniteArrays v0.15 which is breaking CI in the PR JuliaLinearAlgebra/LazyBandedMatrices.jl#137 |
|
I wonder if this is a bug in the Pkg server (or storage server)? cc: @staticfloat @fredrikekre |
|
Okay, here's what I'm getting now. |
|
And note that |
|
I'm hitting this with [email protected], released 11 hours ago. |
|
Something still seems up: Requesting the The same doesn't happen with the default |
|
I don't think the |
|
|
|
I could update my package a few minutes ago. Seems to work for me. Cheers |
|
Thanks for the detailed descriptions about this issue. For me it is still out-of-date (UK). Do you have any tips on figuring out which registry I default to? Also, is there a list of all Julia registries somewhere? An extremely useful workflow would be to verify all registries are up-to-date before pushing updates to clients – since any out-of-date registry might break applications until the new packages are available. (e.g., my python library automatically updates the Julia packages - which would fail until the registries are all updated) Edit: here's an attempt in case others want something: #!/bin/bash
channel="conservative"
base_url="https://%s.pkg.julialang.org/registries.${channel}"
regions=(
"au"
"eu-central"
"in"
"jp"
"kr"
"sa"
"sg"
"us-east"
"us-west"
)
urls=()
for region in "${regions[@]}"; do
urls+=("$(printf "$base_url" "$region")")
done
for url in "${urls[@]}"; do
last_modified=$(curl -sLI "$url" | grep -i "last-modified" | awk '{$1=""; print $0}' | sed 's/^ //')
echo "$url: $last_modified"
doneAlthough this only does the |
|
My local package server in the UK is still out-of-date. I am trying to push a bug fix to downstream users but it's been 22 hours now without the storage server being updated :/ Is there anything I can do to help push this along? (Downstream users will all be on |
|
Which package server are you currently being routed to? That is, what do you get when you run the following on your local machine? curl -X GET -I pkg.julialang.orgSpecifically, what's the |
DilumAluthge
changed the title
eager registry flavor is significantly lagging behind the master brancheager registry flavor is significantly lagging behind the master branch
DilumAluthge
changed the title
eager registry flavor is significantly lagging behind the master brancheager registry flavor is significantly lagging behind the General registry's master branch
|
Hmmm, for me, There are two @fredrikekre Any idea why one |
|
I'm still not seeing 1.0.3 or 1.0.4 of BasicAutoloads, one of which is more than 24 hours old. Requesting eager fixes it, but 24 hours of latency is quite a lot: shell> curl https://raw.githubusercontent.com/JuliaRegistries/General/refs/heads/master/B/BasicAutoloads/Versions.toml
["1.0.0"]
git-tree-sha1 = "f0b29630f259d7d218b6cfa45ee3d2d67a010da4"
["1.0.1"]
git-tree-sha1 = "f15954212241fe1fcb8b36a52fc2d0913c8863d8"
["1.0.2"]
git-tree-sha1 = "3aaa0991207215dc7d21705d868a1bea5c40a108"
["1.0.3"]
git-tree-sha1 = "8527f3827129547d14164f60c1ce4db06979526e"
["1.0.4"]
git-tree-sha1 = "5854c10828e40cee88c8888f8d91a58888f86789"
(@v1.11) pkg> activate --temp
Activating new project at `/tmp/jl_z5w6Wz`
(jl_z5w6Wz) pkg> add [email protected]
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package BasicAutoloads [09cdc199]:
BasicAutoloads [09cdc199] log:
├─possible versions are: 1.0.0 - 1.0.2 or uninstalled
└─restricted to versions 1.0.4 by an explicit requirement — no versions left
(jl_z5w6Wz) pkg> registry update
Updating registry at `~/.julia/registries/General.toml`
(jl_z5w6Wz) pkg> add [email protected]
Resolving package versions...
ERROR: Unsatisfiable requirements detected for package BasicAutoloads [09cdc199]:
BasicAutoloads [09cdc199] log:
├─possible versions are: 1.0.0 - 1.0.2 or uninstalled
└─restricted to versions 1.0.4 by an explicit requirement — no versions left
julia> ENV["JULIA_PKG_SERVER_REGISTRY_PREFERENCE"] = "eager"
"eager"
(jl_z5w6Wz) pkg> registry update
Updating registry at `~/.julia/registries/General.toml`
(jl_z5w6Wz) pkg> add [email protected]
Resolving package versions...
Installed BasicAutoloads ─ v1.0.4
Updating `/tmp/jl_z5w6Wz/Project.toml`
[09cdc199] + BasicAutoloads v1.0.4
Updating `/tmp/jl_z5w6Wz/Manifest.toml`
[09cdc199] + BasicAutoloads v1.0.4
Precompiling project...
✓ BasicAutoloads
1 dependency successfully precompiled in 1 seconds
1 dependency precompiled but a different version is currently loaded. Restart julia to access the new version |
|
IMO, |
|
Probably a week delay would be excessive, but I think 48 hours or less is probably okay. |
|
Is there a reason I might be especially screwed because lot of my users are in Python via PythonCall.jl — PyPI and conda-forge are updated instantaneously. This means that whenever Julia’s package registry gets out-of-sync, their installs will just completely fail due to not being able to find the new backend. I guess I could automatically set their env variable but perhaps seems a bit fragile |
|
As far as the default value: If the user doesn't specify the environment variable, then Julia/Pkg will default to So, in most cases (e.g. normal local usage), the default will end up being However, in certain situations, you might end up observing a different default. For example, in GitHub Actions CI, if you use |
|
Just saw your comment. Give me a minute, I'll write up a few sentences explaining why |
|
So, here's the reasoning for why When using the When using the Consider three different groups of users:
My concern is that if we switch the default to In contrast, the users in group 3 tend to be more experienced in Julia. For example, they might be Julia package developers that want to install the latest version of the package that they just registered. These group 3 users are more likely to be familiar with Julia and thus are more likely to be participating in JuliaLang communities (such as Discourse, Slack, Zulip, GitHub, etc). So it's more likely that they'll know where to reach out for help on one such platform. |
I'm not sure I 100% understand your use case - you have both a Julia package and a Python package, and you register a new version of your Julia package (in the General registry) at the same time you upload a new version of your Python package (in PyPI and/or conda-forge), and each specific version of the Julia package only works with a specific version of the Python package? (We can move this conversation somewhere else, to save people the notifications.) |
|
My packages are still not updating (UK)... I don't really know the "eager" or "conservative" distinction just using the default |
|
@DilumAluthge Thanks for explaining all of this. My follow-up question would be – could we have @dlfivefifty same for me (also UK). Even using |
|
@dlfivefifty Can you try with the @MilesCranmer When you use the As far as the question about "falling back" to |
For me, even in CI with the eager option, it takes more than 10 hours for the pkg server to update. |
|
Yes eager worked |
EDIT: Please disregard this comment. I completely misread the previous commenter's comment (I thought the comment said "conservative" instead of "eager".) |
10 hours is OK for conservative. But for eager, it is too long because it leads to annoying CI failures, which is painful for a pacakge developer. |
|
I am so sorry - I completely misread your message. Yes, I agree - in my opinion, if Just to double-check: in CI now, the |
Happy to know that the Pkg server team has implemented some fixes. I will check it later. |
|
Thanks for the continued engagement @DilumAluthge, much appreciated. More info on the Python-Julia thing, usually what I’ll do is wait for my Julia package updated to be registered for 24 hours before pushing my Python wrapper to PyPI, just in case. But once in a while the Julia registry takes longer (usually for only some availability zones), so I’ll get some emails from users that installation failed - since the Python wrapper is versioned to a specific Julia backend. |
In these cases, are the failures occurring only when a user is installing your Julia package for the first time? If so, the easiest approach might just be to add the instructions for using the Also, how are the users installing your Python package. Do they manually install it themselves (e.g. they run the |
|
PySR uses juliacall (PythonCall.jl). Users will run: pip install pysrThis will download the current version, say 1.0.3. Then they import it, and juliacall automatically installs Julia and Now if a user is unlucky, they might be in an availability zone that is slow. So even if I wait 24 hours as a precaution before uploading to PyPI (which propagates instantly), the Julia pkg servers might still be out of date. This will instantly fail their install step since it can’t find the right backend. |
|
Hmmm. So, |
|
Yes exactly. My one concern is if I force For a long time I had it attempt to download SymbolicRegression.jl directly from GitHub at the specific tag. The issue with this is precisely that many people could not clone (either due to missing git, or some firewall reason), so I switched back. |
|
Something like MilesCranmer/PySR#765 might work for your use case. It first tries with In the case where the user had already set |
|
Thanks! Will try it out. If it is a robust workaround it could probably go in Tangentially, I’m curious—why does the package registry take that much time to update? I wonder why many other package indexes are virtually instantaneous or at worst, minutes, but Julia can take several hours (up to days, although such cases are rare). Are we doing something completely differently than others (and can we switch)? Is there something being computed on the servers that could be computed on the end user machine ? |
|
In this case, I think there was a bug in the Pkg servers. Fredrik Ekre and others have been working to fix it. Normally, there's not too much lag between I'm not super familiar with the Pkg server architecture. It's possible that there is room to optimize the performance, particularly when it comes to processing big artifacts. |
I've released a new version of CombinatorialSpaces.jl a few hours ago when writing this but it seems like that release hasn't made it to the General registry yet. Just to confirm the issue isn't with this specific release I've tried with a few other packages unrelated to this one and going back even further, even like 12 hours ago, I can't seem to update to the newest versions of those either.
There probably isn't, and can't be I suppose, a guarantee on how long this propagation can take but this feels like significantly longer than usual.
The text was updated successfully, but these errors were encountered: