JuliaLang
Launch the manifest-specified Julia version
Closes #10.
Auto-installing would be the next step, but let's do that another day :slightly_smiling_face:.
Code review would be great, I haven't written rust in years :wink:.
Things needed before we can merge:
- [ ] Unit tests for command line parsing functions
- [ ] Feature tests for the entire new functionality
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.
I just added this to the PR here via a direct push.
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.
If you take a look at the revised code, you should see the current get_project contains less general code.
Out of curiosity, why would we want to know whether it's being run interactively or not?
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 juliaup update to update" with just a "Do you want to update (y/n)?" interactive prompt, but we must make sure to only show these interactive prompts when Julia itself is run in interactive mode.
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).
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 Manifest.toml.
If you don't specify the Julia version any other way, this will specifically look at the
Manifest.toml.
I must admit that this may be a reason for me to stop using juliaup in the future. If I set a default channel in juliaup and use the latest language features, I would still like to get the default channel. Please add a config option to opt-out/opt-in into this feature!
Image the world in a year or so (let's say after the release of 1.13). Everyone will then have Manifest-v1.11.toml, Manifest-v1.12.toml, Manifest-v1.13.toml, Manifest-v1.14.toml (for the upcoming rc), and Manifest-v1.15.toml (for nightly), but if one forgets to delete the old Manifest.toml from nowadays, one would still get 1.10 per this feature.
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... :shrug:
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 julia compat section in the Project.toml, cross-check that with the Julia version in the manifest, and if this project could be updated to a newer Julia version, prompt the user whether they want to update the project before the actual Julia launches. We'll need various ways to store answers etc, but roughly that is how I imagine this will work out.
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.
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'm not sure I follow. Why would versioned manifest files be a niche thing? If you want to check your manifest files into source control, and you also want your project to support multiple Julia versions, then versioned manifest files are the only way to reliably accomplish that, right? And this seems like a pretty common use case to me.
The General registry has been using versioned manifests for our CI for a long time now. It's an important component of how we maintain CI stability on the registry. See https://github.com/JuliaRegistries/General/tree/master/.ci, where we have our Manifest.1.$minor.toml files.
If you want to check your manifest files into source control, and you also want your project to support multiple Julia versions, then versioned manifest files are the only way to reliably accomplish that, right? And this seems like a pretty common use case to me.
Is it common, though? I've always thought that we generally discourage folks from checking in manifests as part of packages (which really in my mind are the main use-case where one is trying to support multiple Julia versions at the same time). But at least in my world of research, where we do check-in manifests for say replication code for a paper etc, we really have zero need to support multiple Julia versions at the same time. On the contrary, we really don't want to do that, we just want to have projects that pin down everything, so that anyone trying to run them gets as close as possible to using exactly the same pieces of software that was originally used, including the Julia version.
The General registry has been using versioned manifests for our CI for a long time now.
Ok, but that strikes me as the definition of a niche use-case ;) For the LS we also do something similar, but like how many projects really fall into that kind of Julia-infrastructure category?
Having said that, even if I'm completely wrong about this, I don't really think it changes how we would want to design this feature here?
I started adding tests. They are by no means complete, i.e. we really need to come up with a much more thorough feature test suite.
BUT, I think the tests already uncovered a bug, i.e. it seems to me that the launcher at the moment isn't handing --project correctly. I left a comment at the relevant test. @tecosaur could you take a look?
Work on this continues now in https://github.com/JuliaLang/juliaup/pull/1087
And now it continues in https://github.com/JuliaLang/juliaup/pull/1095.