-
Notifications
You must be signed in to change notification settings - Fork 85
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
Launch the manifest-specified Julia version #1059
base: main
Are you sure you want to change the base?
Conversation
82fcbf0
to
943c9da
Compare
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.
Very cool!
I'll open a PR against this branch here later today with a config option so that this can be behind a feature flag for a while.
Looking at all the command line parsing, I'm wondering whether we should factor that out a bit more and make it more general than mix it into the rest of the logic as it is right now. In particular because we will also want to know soon whether julia
is running in interactive setting or not, which will require more understanding of command line flags.
I just added this to the PR here via a direct push. |
62d7561
to
93314c0
Compare
If you take a look at the revised code, you should see the current Out of curiosity, why would we want to know whether it's being run interactively or not? |
I'd generally like to replace the current prompts that say "Run For this feature here that would also be relevant: when run interactively, we could prompt for "This project requires Julia version X, do you want to install it (y/n)?", but in non-interactive mode we should just error (and ideally also offer a command line argument that triggers automatic installation). |
Ah yep, I can see the use of that. I'd be happy to PR that too later (the detection function, not the prompts). |
93314c0
to
42b5d4e
Compare
When running `julia` with no extra arguments, and no explicit version, it is best to match the manifest version. This is done by implemented a limited form of the Julia executable's argument parsing and load path interpreting to determine the appropriate project to inspect, and then some light ad-hoc parsing of the manifest. We can then search the installed versions for a matching minor version, and run that.
42b5d4e
to
214c97d
Compare
Maybe a stupid question: Starting with julia 1.11, I can have multiple manifest files in one folder. Which one does this feature here choose, if I have a Manifest.toml with 1.10.5, Manifest-v1.11.toml with 1.11.0 and Manifest-v1.12.toml with some 1.12-DEV version? |
If you don't specify the Julia version any other way, this will specifically look at the |
I must admit that this may be a reason for me to stop using Image the world in a year or so (let's say after the release of 1.13). Everyone will then have |
If you want to use the latest Julia in a project, you can just update the manifest to the newer Julia version, or only have versioned manifests... 🤷 |
In my mind the versioned manifest files will be more of a niche thing, at least that is how I imagine things will play out once this feature here lands. I do think we should have good UI that makes it super, super easy to update a project once a new Julia version comes out. I generally imagine that if you launch Julia with a project that the launcher will check the |
Indeed, I don't think David or I see this as the "final destination" so much as a massive first step to more conveniently reproducible Julia environments. |
Closes #10.
Auto-installing would be the next step, but let's do that another day 🙂.
Code review would be great, I haven't written rust in years 😉.
Things needed before we can merge: