Oh alright, yeah that’s a pretty common use case actually.
Thank you!
I’m not sure how that solves the “library A has a locked version of B but dev boxes for apps using A pull another version of B” though.
lud
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Well normally that is solved by simply having mix.lock checked in, and then everyone gets the same deps. BUT that isn’t reliable if someone can check in a mix.exs with an out of sync mix.lock. Then, the next dev to pull down the library code will mix deps.get and get a new lock file.
So it’s really the combination of this together:
- Check in
mix.lockso that deps are specified precisely and repeatably. - Use
--check-lockedin the CI to detect if themix.exsfile has drifted from the lockfile.
1
lud
I was referring to this:
I understand now why using --check-locked is interesting (actually I just added it to my own CIs) but I don’t see how it changes the need to try to build after deleting the mix.lock to see if everything is fine.
Sorry I may be too tired today to understand all of it.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Oh ya I still think that the advice of having a CI task which deletes mix.lock and then tries to build / test is a great idea for libraries.
That said, I probably wouldn’t put it as a requirement for merging a PR. That is to say, if someone is trying to contribute to my library, I do expect the library to build and the tests to pass at the versions locked in the lock file. I want to know if maybe there’s some release out there which is going to require changes in my library, but that could be completely unrelated to the work of the contributor, and it isn’t reasonable to force them to solve that problem just because some dependency out there has a new version.
I would probably only run that additional task on main, so that I (and other contributors) can see that there is some maintenance work to be done to make sure it builds on the latest dep versions.
3
LostKobrakai
I’d even argue that such a test is most useful when run regularly (e.g. nightly) and not run coupled to developer activity. It’ll be far more likely to catch issues that way if the intention is to catch them before users do.
1
fmcgeough
This may make perfect sense. I think if I wanted to enforce --check-locked on my open source library I’d put notes about it in CONˇRIBUTING.md (and CHANGELOG.md) and ask that the person making the PR check-in the modified mix.lock file.
I use Mat Trudel’s github actions for my open source libraries. This just uses mix deps.get.
When I work for a company I’ve added --check-locked for the applications CI. It’s helped reduce confusion and made engineers more aware of what’s going on.
0