What is not realiable here? If you correctly create you environments, they can reliable be reproduced. If you are not running them with Manifest.toml you are only guaranteed your [compat] section in Project.toml, or if you are not running them in the top level of your environment stack you don’t have specifik version guarantees either. But that is documented, that is not how you should use them if you want to recreate them reliably.
I said I thought it would be reasonable that this should error in case of version mismatch, but I think a lot of the time it will be no problem.
But if this is not possible? If you have package A in your default environment, which then depends on an old version of package B, and in the current environment you have added a new version of package B. What should happen when you first use B and then use A? I don’t see a good way to get everything you are asking for.
To me there are a few options:
- Don’t allow stacked envs since it is pretty impossible to guarantee everything will always work well. Now you have to add dev tools to every local env you work on.
- Consistent stacked envs, where each time something is installed in an environment, it also has to make sure all versions are compatible with the parent environments. This could maybe be nice, but I also see downsides with it since the default env may then negatively affect the versions you can use for you package.
- The current strategy, allow mismatch in versions and prioritize the current environment. This will allow for a current environment that is not constrained by your dev tools, while still allowing you to keep the devtools out of the project environment. There might be version problems occasionally, and this is not nice.
- As discussed above, the current strategy with the addition that any version mismatch will generate an error. I think this would be a good balance. You can trust that the code that runs is using correct versions, and you have the convenience of stacked envs.
I disagree, “if you want correctness you do it one way, if you want convenience you do it another way” is more what I feel I said. You can have the correctness by adding everything to the current env. Then you will be sure that the version loaded is from the current env and that it is compatible with all the other versions in the current env (as far as one can be certain of that in the current ecosystem, which is probably a bigger problem than what we discuss here).