Say I have a project, it has its Project.toml and Manifest.toml files. Everything works right now. How can I freeze/pin the versions of everything this project uses so that whenever I use this project in the future it will work? So while my environment marches on and updates everything in its stack, whenever I use that specific project, it will only use the (now) old versions that work. And then at some point in the future I might decide to upgrade this project and release those restrictions.
Just don’t update the project’s environment? The Manifest.toml already nails down all packages and their versions. Just make sure that you aren’t implicitly using packages from an environment that’s deeper in your LOAD_PATH (like the default environment v1.1)
1 Like
Yes, and be sure to check in both the Project and Manifest files to version control. I’ve also used git tag to mark where I have a known working environment in case I later accidentally ] up. That way, you can keep developing other parts of the project, but you can always go back and grab a copy of those files and reinstantiate the environment of something goes wrong.
2 Likes
My only concern about checking in the Manifest.toml is that my understanding is that it would make CI run in the exact same environment all the time. In other words, I don’t catch errors from mistaken assumptions about other packages (eg insufficiently narrow version bounds) and similar.
Of course I can always do a Pkg.API.up() I guess, but I am not sure where it goes in the .travis.yml.
So this means that if I do not julia --project in the package’s repo and then ]up then that package will stay fixed in that sense. And therefore all my own (local and githubed) packages are not affected when I update my default environment (i.e. do a (v1.1) pkg> up). So if I wanted to update them all I’d need to go into each and everyone of them and update them manually (which is a good thing).
Do you not have a test-specific environment? If you have a Manifest.toml in MyPackage, and then your test environment does using MyPackage, Test the Manifest.toml in MyPackage doesn’t get consulted - what matters is the test/Project.toml (and if you had it, the test/Manifest.toml, though I don’t think that’s necessary).
Though now that I’m writing this, I don’t know what happens if you do ] test MyPackage locally - I would have thought it’s the same, but Stefan has said that the reason to include the Manifest.toml in the first place is that it guarantees you have at least one tested environment that works, so…
Correct, if you do not explicitly ] up in the project’s environment the toml files will stay as they are, forever. The project’s environment is completely independent from the default environment.
1 Like