`mix.lock` in libraries/packages

Chat / Discussions
, ,
1

I want to share some concerns about storing mix.lock file in VCS for libraries. The current version of Library Guidelines page has zero mentions of mix.lock and the established community practice is to indeed version control mix.lock.

Which is meaningless and might be even harmful in some scenarios.

Consider the library A that depends on another library B. B occasionally introduces a breaking change in the minor updates. Even if A library has nightly builds turned on, it continues to be green because in mix.lock there is a previous version of B. All the projects, depending on A get broken, because they ignore A’s mix.lock.

Without mix.lock in the VCS, A library author would have been informed a night after B upgrade. With mix.lock file in VCS, they will be informed by a tornado of issues from A users days after.

A less exotic case might be also taken into account: A depends on B and C, then B and C start conflicting on D at some point, but A nightly builds are still all green, because there is mix.lock in VCS and A is never tried to compile against modern versions of B, C, and D.

This is all not expected in our great self-organized ecosystem, but things happen. Currently, I personally switch nightly build on and remove mix.lock from VCS. It makes me think I will, at least, be notified about issues with the latest dependencies consistency the very next night.

I think removing mix.lock from VCS for libraries is a good practice in any case and I think we might enforce/suggest it via Guidelines I linked above.

Thoughts? /cc @josevalim

1 Like
2

The benefit of mix.lock is making builds reproducible. You don’t want contributors to jump into a library and then become unable to write a patch because they can’t get their tests to pass anyway.

If the goal is to catch bugs, then I recommend having additional builds on CI that remove the lock file before running. Then you get the best of both words.

5 Likes
3

Eh. Does not that mean that projects using that library cannot use that library because of, well, above?

Or, even worse, they can get it to compile, but tests were red in this env, if they were ever attempted?

4

If a new version of library A’s dependency B breaks A, and I’m some contributor trying to fix some other, unrelated bug in A, how does it benefit me or the owner or the owner of A that I’m stuck and can’t move forward?

If that were the only way to know about breaking updates to B then sure, but as Jose noted, this is solved with a CI setup that simply unlocks everything before running tests. Perhaps that suggestion is what is missing from the guides?

5 Likes
5

Seems like a best solution, yes. I would strongly appreciate putting it there to alarm future library owners, yes. Shall I provide a PR?

6

A PR that recommends checking it under version control and running a separate build without it would be welcome, yes. :slight_smile:

3 Likes
7

On it.

8

FWIW, I’ve found the same issue, and in CI I’ve started deleting the mix.lock before getting deps and running tests. :+1: to removing it for libraries; regardless, I’m hopeful that this isn’t a common problem.