-
Notifications
You must be signed in to change notification settings - Fork 196
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
ERROR: The following package names could not be resolved/Julia servers out of date #27
Comments
Server seems to have updated. Closing. |
Unfortunately appearing again for v0.5.10. I have pinned this issue in case some of the Julia servers are out of date - just follow the above commands to get it working. |
For the impatient, I would just do the following to get the freshest release.
You can also replace master with a tag or commit hash. For example, you might this instead:
|
Thanks! I wonder if I should have PySR specify the |
If this is meant as a library, I would not include the Manifest.toml. I typically only include the Manifest.toml for terminal projects that I may want to reproduce exactly. |
Oh I meant for the point about including SymbolicRegression.jl based on the git repo URL, rather than the Julia registry. I'm not sure how else to do that, for PySR users, other than to include a fixed Manifest.toml. (is there any way to enforce that in a Project.toml?) |
How users install your package is up to them not you, ultimately. For some, they either have to use specific mirrors or proxies for reliable access in their geographic locations. This is the problem that the pkg server protocol solves by providing a way to mirror and verify packages in a distributed and versioned fashion. Pointing to your specific repository is a secondary option for those who cannot wait for the pkg servers to catch up and who also have reasonable direct access to Github. So for the kind of package I think you are providing, I would recommend not including the Manifest.toml. |
This would be true if they were using the Julia API, but for PySR, I think this is only true for a handful of power users who know the The current approach to version control of Julia packages from within Python is to literally generate Lines 340 to 358 in 1178fa3
|
I'm not sure if I'm following why that is necessary. Couldn't you just run this code? using Pkg
Pkg.activate(; temp=true)
spec = PackageSpec(name = "SymbolicRegression", uuid = "8254be44-1295-4e6a-a16d-46603ac705cb", version = v"0.7.7")
Pkg.add(spec) |
Thanks, that definitely looks like a cleaner way to do it! (note I will be running this from PyJulia, not Julia) Quick question: I found the |
Yes, the |
Starting with v0.7.4, #27 will never be an issue again since SymbolicRegression.jl is downloaded directly from the GitHub repo. Unpinning. |
tl;dr, delete
~/.julia/registries/General
and then run the following commands in Julia:(original post)
FYI I pushed v0.4.2 of SymbolicRegression.jl to the registry 15 hours ago, which is required for the latest PySR. However, the registry server is still not updating - which seems like an issue that sometimes happens: JuliaRegistries/General#16777.
To get the Julia registry to stay up to date even if the registry server fails, you can use the git version instead. This can be done as follows:
~/.julia/registries/General
This will install the git version of the registry, which is always up-to-date.
The text was updated successfully, but these errors were encountered: