Ouch you just pressed my rant button! These nested environments are probably the Julia feature I dislike most. I mean, the documentation says:
There are a couple of noteworthy features of this design:
[…]
2. Packages in non-primary environments can end up using incompatible versions of their dependencies even if their own environments are entirely compatible. This can happen when one of their dependencies is shadowed by a version in an earlier environment in the stack (either by graph or path, or both).
To me at least that’s not a “feature”, that’s a bug. I find it crazy that this is done implicitely and by default. The documentation continues with
Since the primary environment is typically the environment of a project you’re working on, while environments later in the stack contain additional tools, this is the right trade-off: it’s better to break your development tools but keep the project working.
No no no. Please stop the madness. I already have enough problems with legitimate bugs in my code! I don’t want undefined behavior as part of the design just because it makes some things convenient!
Also there’s nothing in the language to enforce the idea that the parent environments are just for developer tools. My guess is there are lots of projects out there that use nested enviroments for sub-projects.
Maybe worst of all: we like to say “Julia projects are reproducible because the dependencies are recorded in the Project.toml and Manifest.toml” but because of this feature it’s not true. The language should guarantee this by default at least but it doesn’t.
I wish there were no implicit nesting of environment. Inheritance from a parent should be explicit. Here are two ideas:
- Using
Subproject.tomlinstead ofProject.tomlcould activate inheritance from the closest parent. - Project files could support an include directive.
I prefer the first idea but in any case, incompatible dependencies should raise an error. Sounds like something that shouldn’t need to be said.
/rant