Ensuring that julia is configured same way across all developers working on repository

General Usage
1

Hi,
so I have a mono-repo.
One fairly small part of it is a julia package.

Most people i work with are not julia experts so don’t know a lot about configuring Julia in a sensible way.

I would like to basically check some files into my repo that ensures julia is always started up with good defaults.

We currently ship with the repo our .vscode settings for the project that automatically configures language server extensions and auto-formatters etc for python and julia.
And pyproject.toml constrolling configuation of manythings, especially pixi, which automatically defines a lot of our tools and how to use them,

I would like to do similar for julia.
In particular I would like to configure so:

  • with a particular set of commandline flags (e.g. --check_bounds=yes)
  • a particular set of enviroment variables (e.g. ENV["JULIA_PKG_PRESERVE_TIERED_INSTALLED"]="true")
  • a particular julia version (probably 1.11 right now)
  • Maybe a particular startup.jl and “global” enviroment. to e.g. load Revise.

Additional considerations:

  • I want to do this in a way that minised duplication with the setup for JuliaCall, which i currently do via near the default pyjuliapkg.
  • I want to do this in a way that minises duplication with CI configuration
  • I want to minimize manual steps.

Bash script idea
One idea would be to ship a bash script, that runs julia after setting these things and these flags.

  • the bash script whould as it’s final step run julia with the options set and pass any commandline arguments on to it.
  • I could setup the “global” enviroment by shipping a project.toml + manifest.toml for it and I could add it as global by putting it in the JULIA_LOAD_PATH (using the stacked enviroments feature).
    Anbd
  • I could commit the configuration settings for vs-code Julia extension to make it point at this bash script instead of at the actual julia executable.
  • installing julia via juliaup is only step.

Downside is that if they run julia outside of vs code they would need to know to run this bash script instead.

Pixi idea
Another option would to do similar, but do it via a pixi task, instead of a bash script.
Key advantage everyone using the mono-repo is used to starting things via pixi.
This might also have the advantage that could install jula itself via pixi.
I feel like someone got julia conda installs working again recently, right?

Not 100% sure on how hooking any of this up via CI or JuliaCall would go.

2

I don’t know if this is a complete solution but with the Bash script approach, you could conceivably add it as a channel in juliaup and set that as the default:

$ cat fake-julia.sh
julia +1.12 --threads=4 ${@}

$ juliaup link fake ./fake-julia.sh

$ juliaup default fake

And then any local invocation of julia will use these flags.

Although don’t do the mistake I did: when I tested this I originally just made the fake script do julia --threads=4 ${@} without an explicit +1.12 channel. After running juliaup default fake, launching julia would hang because it would search for the default channel, which resolved to the fake script, which searched for the default channel, etc…