match against environment manifest version before using the default channel #1315

KristofferC · 2025-10-30T22:50:40Z

alternative to #1095

I am not much of a rust programmer so I kind of wrote pseudo code and had Claude Code translate it for me. Should still do some manual cleanups.

In use:

~/JuliaPkgs/TimerOutputs.jl
❯ julia --project -q
Info: Installing Julia 1.10.10 automatically per juliaup settings...
Checking for new Julia versions
Info: Successfully installed Julia 1.10.10.
julia> VERSION
v"1.10.10"

# Change the manifest file

~/JuliaPkgs/TimerOutputs.jl
❯ julia --project -q
Info: Installing Julia 1.10.8 automatically per juliaup settings...
Checking for new Julia versions
Installing Julia 1.10.8+0.aarch64.apple.darwin14
Info: Successfully installed Julia 1.10.8.
julia> VERSION
v"1.10.8"

DilumAluthge · 2025-10-30T22:55:54Z

src/bin/julialauncher.rs

+
+    // Search for manifest files in priority order
+    // JuliaManifest.toml takes precedence over Manifest.toml
+    for manifest_name in ["JuliaManifest.toml", "Manifest.toml"] {


Needs support for {Julia,}Manifest-vX.Y.toml

One idea:

Loop over all files in the directory. Ignore folders.

Collect only the filenames that match the allowed patterns.

I think it would also be reasonable (and in my mind a bit less magical) to say that version selection via the manifest only happens from a JuliaManifest.toml or Manifest.toml file.

The {Julia,}Manifest-vX.Y.toml manifests would then only come into play if one used a higher precedent order override.

DilumAluthge · 2025-10-30T22:56:51Z

How should this work if the project directory has multiple versioned manifests, e.g. Manifest-1.10.toml and Manifest-1.12.toml?

KristofferC · 2025-10-30T23:12:01Z

Probably the highest version?

DilumAluthge · 2025-10-31T20:34:51Z

Probably the highest version?

That seems okay.

If the user explicitly provides the desired version (e.g. julia +1.10 --project or julia +1.10.3 --project or julia +lts --project), we'd respect the Julia version specified by julia +ver, right?

KristofferC · 2025-10-31T21:00:23Z

If the user explicitly provides the desired version (e.g. julia +1.10 --project or julia +1.10.3 --project or julia +lts --project), we'd respect the Julia version specified by julia +ver, right?

Yes, if you look at the priority in the README (which I updated here) it is:

1. A command line Julia version specifier, such as `julia +release`.
2. The `JULIAUP_CHANNEL` environment variable.
3. A directory override, set with the `juliaup override set` command.
3. The default Juliaup channel.
4. Automatic version selection based on the active project.
5. The default Juliaup channel.

So an explicitly provided version has top-priority and will always be used.

DilumAluthge · 2025-10-31T21:09:46Z

BTW I think item 3 should be removed from that list? Redundant with item 5, and IIUC you prefer item 4 over item 5?

KristofferC · 2025-10-31T22:17:11Z

I don't fully understand why it is redundant or why this PR makes it more redundant.

davidanthoff · 2025-10-31T22:22:33Z

I believe @DilumAluthge was just looking at the list as pasted in the comment here, where there are two 3) items. It is all correct in the PR that modifies the README.

KristofferC · 2025-10-31T22:32:07Z

Oops, I must have copy pasted from the diff.

KristofferC · 2025-11-01T15:43:31Z

I realize a better way of testing this is (of course) to call julia itself with the same project flag and env variable and get the truth from that.

IanButterworth · 2025-11-02T04:18:11Z

Just had a thought.. how does this handle manifests from julia master, i.e. 1.14, given that there's no "1.14" channel? I guess there isn't a "1.13" either.

KristofferC · 2025-11-02T07:52:15Z

It uses nightly channel if the version is higher than any known version. But maybe it should emit some warning when that happens...

tecosaur · 2025-11-03T10:12:19Z

I may be missing something, but why is this ~3x the LOC of #1095? Is this PR larger in scope?

I do notice that #1095 was written before versioned manifests became a thing, but that seems like just a handful of extra lines.

KristofferC · 2025-11-03T12:30:37Z

I can remove tests if you want to... But as I have said, you are free to reopen your PR and we can try them on a bunch of cases. But based on

I don't think it's realistic that I'll get around to writing the missing tests, let alone resolving the merge conflicts any time soon.

I thought you didn't plan on getting back to that "any time soon" so I started this. I don't know if four days counts as "any time soon" or if just the fact that someone else started working on it made your desire come back.

However, some things that this does that might be different from that branch:

Launch +nightly if the version is > than anyone version we know
Launch 1.x+nightly if x is > than any version we now for 1.x
Expand ~ to homedir
LOAD_PATH
Logging
Versioned manifests
Maybe more, didn't look more.

tecosaur · 2025-11-03T12:47:24Z

I can remove tests if you want to... But as I have said, you are free to reopen your PR and we can try them on a bunch of cases. But based on

Oh, I'm talking about the non-testing code. Taking a slightly closer look, it seems like ~700 LOC compared to ~400 in the original PR, which doesn't seem too bad given the extra functionality you mentioned.

I thought you didn't plan on getting back to that "any time soon" so I started this. I don't know if four days counts as "any time soon" or if just the fact that someone else started working on it made your desire come back.

Yea, I wasn't thinking of getting back to this any time soon when I said that. I also have a track record of getting around to things later than I expected, which I try to account for.

After making that comment, and given you said that functionality seems needed, I then thought I should just "take a peek" at it that evening to see how bad the merge conflicts really are, and then we talked about how the functionality should work over Slack, and all that moved the work from back-of-mind to front-of-mind. I tend to work on what I'm thinking about.

Net result: I've ended up poking at this months earlier than I thought I would. If there is value in me spinning up that branch again, it's much more viable than it was four days ago. However, if Sonnet 4.5 can't take care of the test writing, or for some other reason the work ends up in limbo again, I don't currently have the motivation in this area to keep working on this for a prolonged period.

Looking at how hard adding project/nightly/versioned manifest support is, and doing it if it's easy, I am up for (but not much more).

KristofferC · 2025-11-03T13:59:57Z

I rewrote a lot of the implementation here because I realized (while being on the treadmill 🏃‍♂️) that it made a lot of sense to just directly "transpile" the julia code itself that does the project and manifest file resolving. That should make it easier to review, easier to update and more likely to be correct.

As a test of one of the functionality I wanted to use this for I did:

(@v1.12) pkg> app add https://github.com/KristofferC/Rot13.jl
...
[ Info: For package: Rot13 installed apps rot13

which installs the rot13 Julia app. I then set the julia command to run apps with to the juliaup julia and we can see how it detects the julia version in the manifest for the app (which requires JULIA_LOAD_PATH handling support) and uses the correct version:

❯ JULIAUP_LOG=Debug JULIA_APPS_JULIA_CMD=~/juliaup/target/debug/julia rot13 foobar
[2025-11-03T13:54:58Z DEBUG julia] VersionDetect::Found valid project in JULIA_LOAD_PATH entry: /home/kc/.julia/environments/apps/Rot13
[2025-11-03T13:54:58Z DEBUG julia] VersionDetect::Using project file: /home/kc/.julia/environments/apps/Rot13/Project.toml
[2025-11-03T13:54:58Z DEBUG julia] VersionDetect::Detected manifest file: /home/kc/.julia/environments/apps/Rot13/Manifest.toml
[2025-11-03T13:54:58Z DEBUG julia] VersionDetect::Read Julia version from manifest: 1.12.1
sbbone

…hannel alternative to JuliaLang#1095

KristofferC · 2025-11-03T17:05:08Z

I think I am fairly happy with this now. Maybe the number of tests is a bit excessive; I basically added a test as soon as I found something missing or buggy.

DilumAluthge · 2025-11-03T17:49:48Z

Personally I'm always a fan of having lots of tests.

DilumAluthge reviewed Oct 30, 2025

View reviewed changes

KristofferC force-pushed the kc/auto_version_select branch from 2510c05 to 842eafa Compare October 31, 2025 18:52

KristofferC force-pushed the kc/auto_version_select branch 3 times, most recently from 220d16a to 58b6b04 Compare October 31, 2025 22:15

KristofferC mentioned this pull request Oct 31, 2025

also do version detection for portable scripts #1316

Draft

KristofferC force-pushed the kc/auto_version_select branch 3 times, most recently from c846ba4 to 988b305 Compare November 3, 2025 09:36

KristofferC marked this pull request as draft November 3, 2025 11:21

KristofferC force-pushed the kc/auto_version_select branch 2 times, most recently from 0a18fe8 to f0e8600 Compare November 3, 2025 13:56

KristofferC marked this pull request as ready for review November 3, 2025 14:00

KristofferC force-pushed the kc/auto_version_select branch 2 times, most recently from b133d52 to e5e59b0 Compare November 3, 2025 14:03

KristofferC force-pushed the kc/auto_version_select branch from e5e59b0 to 8d605db Compare November 3, 2025 14:27

match against environment manifest version before using the default c…

320a1b6

…hannel alternative to JuliaLang#1095

KristofferC force-pushed the kc/auto_version_select branch from 8d605db to 320a1b6 Compare November 3, 2025 15:27

KristofferC mentioned this pull request Nov 5, 2025

change from using a build script to auto installing kernels and providing a jupyter path update function JuliaLang/IJulia.jl#1215

Open

match against environment manifest version before using the default channel #1315

Are you sure you want to change the base?

match against environment manifest version before using the default channel #1315

Conversation

KristofferC commented Oct 30, 2025

Uh oh!

DilumAluthge Oct 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DilumAluthge Oct 31, 2025

Choose a reason for hiding this comment

Uh oh!

davidanthoff Oct 31, 2025

Choose a reason for hiding this comment

Uh oh!

DilumAluthge commented Oct 30, 2025

Uh oh!

KristofferC commented Oct 30, 2025

Uh oh!

DilumAluthge commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KristofferC commented Oct 31, 2025

Uh oh!

DilumAluthge commented Oct 31, 2025

Uh oh!

KristofferC commented Oct 31, 2025

Uh oh!

davidanthoff commented Oct 31, 2025

Uh oh!

KristofferC commented Oct 31, 2025

Uh oh!

KristofferC commented Nov 1, 2025

Uh oh!

IanButterworth commented Nov 2, 2025

Uh oh!

KristofferC commented Nov 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tecosaur commented Nov 3, 2025

Uh oh!

KristofferC commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tecosaur commented Nov 3, 2025

Uh oh!

KristofferC commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

KristofferC commented Nov 3, 2025

Uh oh!

DilumAluthge commented Nov 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

DilumAluthge Oct 30, 2025 •

edited

Loading

DilumAluthge commented Oct 31, 2025 •

edited

Loading

KristofferC commented Nov 2, 2025 •

edited

Loading

KristofferC commented Nov 3, 2025 •

edited

Loading

KristofferC commented Nov 3, 2025 •

edited

Loading

DilumAluthge commented Nov 3, 2025 •

edited

Loading