Yeah actually it’s not the startup file that was causing package version issues but the environment that was loaded. So the real issue here is to avoid loading packages having version X in the default environment then trying to load version Y in the project manifest as @nhz2 mentioned. And ideally, doing that through DrWatson’s @quickactivate as to avoid hard-coding relative paths in all my julia scripts.
Sorry for the confusion, I’m still getting used to the way Julia works!
I’m not sure the premise here is correct. I never used DrWatson.jl, but I just read its docs and reminded myself of the relevant Julia docs:
--project[={<dir>|@.}]
- Set
<dir>as the active project/environment. The default@.option will search through parent directories until aProject.tomlorJuliaProject.tomlfile is found.
So using the --project (without additional arguments) startup option for julia already provides the functionality of recursively searching parent directories for a project.
Does simply adding --project to your startup options resolve your issues?
Lastly, I’m not sure what do you mean by this:
avoid hard-coding relative paths in all my julia scripts
Humm this is interesting! I fully agree that’s the way I would like Julia to behave! However, either there’s something I don’t understand, or it just doesn’t work that way. Loading the julia executable in my module’s folder (or any of its subfolders) doesn’t seem to load the environment:
julia> using Pkg
julia> Pkg.status()
Status `~/.julia/environments/v1.11/Project.toml`
It should show the toml file from my module, no?
edit never mind, it works by invoking the option without any argument, i.e.
julia --project
I could then just create an alias from julia to julia --project I guess.
This is quite a bizarre error to be having with DrWatson.jl – let me ping the creator @Datseris so he can see this (if he hasn’t already). I am a huge DrWatson.jl fan so to be seeing these many issues is very strange to me when I have barely ever ran into problems with it in my four years of use of the package.
P.S. Four years. Wow. I am getting old. 
I think the new --project=@script option would do what you want when it is working `--project=@script` is broken or NEWS entry is incorrect (Julia 1.11.0-rc3) · Issue #55606 · JuliaLang/julia · GitHub `--project=@script` does not activate script project if outside of the Project Directory · Issue #55069 · JuliaLang/julia · GitHub
Then you could add something like the following to the file’s shebang:
#!/usr/bin/env -S JULIA_LOAD_PATH="@" julia +1.11 --startup-file=no --project=@script
Interesting thanks! I’ll look into that!