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

**URL:** <https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502>\
**Category:** General Usage\
**Created:** [July 28, 2026, 2:15am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502 "2026-07-28T02:15:41Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [July 28, 2026, 2:15am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/1 "2026-07-28T02:15:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![penelopeysm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/penelopeysm/32/213172_2.png) [@penelopeysm](https://discourse.julialang.org/u/penelopeysm)\
**Post date:** [July 28, 2026, 2:48am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/2 "2026-07-28T02:48:36Z")

</div>

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:

```bash
$ 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…

---

<div class="post-metadata">

**Author:** ![scelles](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scelles/32/220408_2.png) [@scelles](https://discourse.julialang.org/u/scelles)\
**Post date:** [July 28, 2026, 7:38pm UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/3 "2026-07-28T19:38:13Z")

</div>

Hi @oxinabox

Have you considered for your use case solution with [Docker](https://www.docker.com/) et [devcontainers](https://containers.dev/) (maybe through [Devpod](https://devpod.sh/)?)

Hope that can help.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [July 29, 2026, 2:04am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/4 "2026-07-29T02:04:09Z")

</div>

I just got julia-forge going again:

> [@Julia-forge, a conda channel for official Julia](https://discourse.julialang.org/t/julia-forge-a-conda-channel-for-official-julia/138511):
>
> A couple of years ago Wolf Vollprecht created a conda channel called julia-forge that repackges official Julia downloads as conda packages: Recently, I revived the project by adding recent stable (1.12.6) and long term support (LTS) builds (1.10.11). I also added an additional LTS channel which does not contain the latest stable builds. The revival mimics logic based on juliaup to monitor version releases. The two channels are meant to mimic juliaup’s release and lts channels. This differ…

I think I almost got things automated but we could probably use more eyes on this repository:

> **[GitHub - wolfv/julia-forge: Recipes for julia (the language) and more](https://github.com/wolfv/julia-forge)**
>
> Recipes for julia (the language) and more

Maybe I should setup a fork in a github org?

Pixi tasks are nice. We should copy that to run binary builder artifact executables.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [July 29, 2026, 3:21am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/5 "2026-07-29T03:21:56Z")

</div>

I hate that, but maybe it is the best way

---

<div class="post-metadata">

**Author:** ![blah\_blah.jl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/blah_blah.jl/32/223304_2.png) [@blah\_blah.jl](https://discourse.julialang.org/u/blah_blah.jl)\
**Post date:** [July 29, 2026, 3:58am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/6 "2026-07-29T03:58:01Z")

</div>

I have also recently started with some Julia based projects and honestly I feel that Startup.jl feels a better option imo… not really sure because of my noob skills but yea this is my take

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [July 29, 2026, 4:05am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/7 "2026-07-29T04:05:00Z")

</div>

> [@blah\_blah.jl](#):
>
> I have also recently started with some Julia based projects and honestly I feel that [Startup.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Startup)

What is Startup.jl ?  
do you mean the `.julia/config/startup.jl` file?  
For a lot of settings, you can’t set them there because that is only read after julia is started, and they need to be set before julia is started.

---

<div class="post-metadata">

**Author:** ![blah\_blah.jl](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/blah_blah.jl/32/223304_2.png) [@blah\_blah.jl](https://discourse.julialang.org/u/blah_blah.jl)\
**Post date:** [July 29, 2026, 4:22am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/8 "2026-07-29T04:22:05Z")

</div>

Well honestly even I have to check it out, from the options which you had pasted originally in post, from my knowledge it felt that start startup.jl feels like the better option, yea based on that I mentioned it in my comment.. and yea if that’s the case then yea one has to evaluate better or to check better

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [July 29, 2026, 5:13am UTC](https://discourse.julialang.org/t/ensuring-that-julia-is-configured-same-way-across-all-developers-working-on-repository/138502/9 "2026-07-29T05:13:26Z")

</div>

I have started replacing everything Docker with a [podman](https://podman.io/). Too much of the Docker ecosystem is non-free (Docker Desktop, Docker Hub).