-
Notifications
You must be signed in to change notification settings - Fork 104
Try to use dmgs first on macos #1320
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
base: main
Are you sure you want to change the base?
Conversation
|
Might be worth sticking a link to this comment as a code comment somewhere here, otherwise people (like me) might forget why the |
|
|
||
| #[cfg(target_os = "macos")] | ||
| fn try_download_dmg_with_fallback(url: &url::Url, target_path: &Path) -> Result<(String, bool)> { | ||
| let dmg_url = if url.as_str().ends_with(".tar.gz") { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should really handle that in the construction of the version db, right? I.e. where there is a dmg file available, the UrlPath path in the version DB should just point to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that but would that be backwards compatible? The db needs to serve before and after we add dmg support
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The version db file itself is versioned, so when we update the schema (which this would essentially be a case of) we would publish it as version db 2 file, so any old client would just stay on the old version file. Would actually be good to test such a version db schema change with a relatively simply case like this one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent some time trying to figure out the database update approach and don't think I understand how to add the v2 database and keep updating the v1 database.
I think implementing that is a bit outside of my wheelhouse...
Do you think we could proceed with this approach for now, with a TODO to update the database version format appropriately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think my original thinking for DB versions was that we stop updating v1 database once we start to publish v2 databases. The general idea for Juliaup is that the binaries need to be kept up-to-date.
I would prefer that we try to do this with a DB update, I'm happy to help with that.
One thing I don't fully understand yet: do we need this stuff for only the PR type channels, or for everything?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, and I can help with the DB update!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
It's needed for all official releases. I'm not sure which of the nightlies or PRs have dmgs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@davidanthoff to try and help this move along I've given the database format changes a go. What do you think?
0eab19a to
9a3cd9d
Compare
WIP, seems to work. Avoids the need for notarizing the stdlib.
Developed with Claude. I haven't reviewed the code closely yet.
I had a previous attempt here #998
And some discussion here
JuliaLang/julia#54366
#1010