-
Notifications
You must be signed in to change notification settings - Fork 81
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
Add a nightly channel #96
Comments
Wouldn't it be better for juliaup to read in the version db from an external source instead of baking in the db version manager with the juliaup source itself, thereby eliminating the need to update juliaup when new nightlies are uploaded? |
Having it baked in simplifies things a lot: don't have to handle the situation where a file gets corrupted, don't have to worry about the file version and the binary version drifting apart, don't have to figure out a way to download version file updates in the background somehow etc. The current approach just makes for a very stable and robust solution, with no real downside. So I think my preference at the moment would be to come up with something special for the nightlies, and leave the "normal" case as is. |
That makes sense to me. The mechanism used for nightlies can be battle-tested and if deemed reliable enough, could then be used for other channels if so desired in the future. |
The way this works is that we mark which versions are nightly versions in the versions db during the build process and then special-case those when added as a channel or when updated. Right now, `juliaup update` will always download new nightly tarballs, which could potentially be wasteful if that's called again in quick succession, but I think for now that should be a reasonable solution. I have also gotten rid of a lot of code duplication in `build.rs`, which should make adding new platforms easier in the future. I hope I didn't miss anything there. Closes #96
The way this works is that we mark which versions are nightly versions in the versions db during the build process and then special-case those when added as a channel or when updated. Right now, `juliaup update` will always download new nightly tarballs, which could potentially be wasteful if that's called again in quick succession, but I think for now that should be a reasonable solution. I have also gotten rid of a lot of code duplication in `build.rs`, which should make adding new platforms easier in the future. I hope I didn't miss anything there. Closes #96
I just tried |
|
As a start, nightlies don't even need a version database. They can just download whatever file lives at |
I think the issue with that may be knowing when to download new nightlies? But perhaps for nightlies it would be fine to try one per day? Or maybe something with ETags? I believe that S3 automatically supports ETags, so this could be pretty simple to implement. |
For my use cases, yestaday's nightly is just as good as today's, so a time-based approach would be fine. ETags would be great if they could be fetched promptly, but the queries I wrote are sometimes quite slow: julia> @time HTTP.request("HEAD", "https://julialangnightlies-s3.julialang.org/bin/mac/x64/julia-latest-mac64.dmg")
24.274753 seconds (632 allocations: 100.922 KiB, 0.05% compilation time)
HTTP.Messages.Response:
"""
HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 118106979
x-amz-id-2: Gbv+lpFooK5eqE8rceZGyb8gqx5r/tmBXwwLM+i5EugUBqaB2DK31ebTMTM+s4NqdZpFJY7fIrY=
x-amz-request-id: BBF9C2X78WGEEH5Q
Last-Modified: Tue, 21 Jun 2022 20:10:10 GMT
x-amz-expiration: expiry-date="Sun, 21 Aug 2022 00:00:00 GMT", rule-id="Cyberduck-u1YrSIk1"
ETag: "bc45bc4361d20c7f72a92bb2481d77ab-15"
Content-Type: application/x-apple-diskimage
Server: AmazonS3
Accept-Ranges: bytes
Age: 268
Date: Wed, 22 Jun 2022 14:32:40 GMT
Via: 1.1 varnish
X-Served-By: cache-nrt-rjtf7700065-NRT
X-Cache: HIT
X-Cache-Hits: 0
X-Timer: S1655908361.691796,VS0,VE72
""" |
Oof, yeah, that's quite slow. What about spinning off a background process that does the ETag thing, updates if there's an update to be had and then exits. That way the nightly would be available the next time you run the command? Would require a bit of locking, of course, but I think that's already needed. |
That sounds reasonable. I think nightly release channel is one of the few cases where it is acceptable to perform automatic silent background updates (i.e. triggered when a user invokes Even with automatic updates in this manner, it is possible for a user to invoke Ideally, we can still support |
That sounds like a great plan to me. |
The way this works is that we mark which versions are nightly versions in the versions db during the build process and then special-case those when added as a channel or when updated. Right now, `juliaup update` will always download new nightly tarballs, which could potentially be wasteful if that's called again in quick succession, but I think for now that should be a reasonable solution. I have also gotten rid of a lot of code duplication in `build.rs`, which should make adding new platforms easier in the future. I hope I didn't miss anything there. Closes JuliaLang#96
The way this works is that we mark which versions are nightly versions in the versions db during the build process and then special-case those when added as a channel or when updated. Right now, `juliaup update` will always download new nightly tarballs, which could potentially be wasteful if that's called again in quick succession, but I think for now that should be a reasonable solution. I have also gotten rid of a lot of code duplication in `build.rs`, which should make adding new platforms easier in the future. I hope I didn't miss anything there. Closes JuliaLang#96
The way this works is that we mark which versions are nightly versions in the versions db during the build process and then special-case those when added as a channel or when updated. Right now, `juliaup update` will always download new nightly tarballs, which could potentially be wasteful if that's called again in quick succession, but I think for now that should be a reasonable solution. I have also gotten rid of a lot of code duplication in `build.rs`, which should make adding new platforms easier in the future. I hope I didn't miss anything there. Closes JuliaLang#96
Since #131 got fixed https://julialang-s3.julialang.org/bin/versions.json is used to find new versions. That JSON doesn't have nightlies. Though it does have the 1.9.0-alpha1 for instance, and with be6719e that is available in the So I guess we need to decide if nightlies belong in versions.json, and if not, juliaup needs to get it from |
I'm wondering what would be the problem to get nightly from |
Yeah indeed, I didn't mean to imply that |
Another case in point that this should be done: Julia GtiHub action has |
For what is worth, it is trivial to do this yourself using the
The first time you do this you also need Now I have a nightly managed by juliaup, and a non-juliaup command line shortcut to update it. |
@Krastanov this is a good workaround, maybe worth posting somewhere visible. But also this is exactly the kind of code I was hoping to avoid when getting |
Bump, this is the last thing we need to reach feature parity with UpdateJulia.jl |
Just FYI, I'm currently taking the PR from @maleadt that we reverted and am modifying that a bit with some of the new strategies we discussed since then. Will hopefully have a new PR soon. |
We'll have to think a bit how we update the version DB for that as we don't want to publish a new version in the store every night... We should probably have a separate version db for nightly builds or something like that, so that we can insulate users that don't deal with that from frequent updates of that. We also need to think about an ID scheme for nightly builds. Presumably there is one already? I'm just not familiar with it :)
The text was updated successfully, but these errors were encountered: