Of course you should version mix.lock! Wait do we..?

I think he explains it pretty well. For production applications, your builds need to be 100% reproducible. Every change you deploy, should be traceable to a diff in your repository whether it is your code, a dependency or a transitive dependency.

Libraries on the other hand, need to “float” - they should be compatible with various versions of their own dependencies, otherwise users get locked to libraries that they cannot upgrade as they need to. This seems to happen a lot in the Java/Maven ecosystem, where no one can build their dependencies from source, and are at the mercy of the slowest upstream to update a new downstream that they need.

The downside of not having a lock in libraries is that contributing to a library may become harder for a newcomer because they may be unlucky to clone it exactly when a breaking dependency is introduced.

Furthermore, you usually have a small group of developers working on a project and their local checkout all have an old mix.lock. So most of the time, you are not updating the dependencies, unless you are constantly removing your local mix.lock file.

If you want to test against latest versions, do it on CI, where you will be running it constantly and without the risk of pushing the burden to new contributors.

This is a good idea. You can set up a specific CI build that deletes mix.lock before running mix deps.get and it will run tests with the same versions users will get when they add your dependency to their project.

What about start up? Because they don t really have legacy when they start. Shouldn they focus on building a realliable dev env for everybody? Rather than locking?
I do agree that If you have legacy code It s the way to go. And even if everybody has the same env you might have to lock anyway. But I just feel like the use case of lock could be narrowed for the greater good. Isn t declarative the best for these kind of problems?

If you are a startup you most likely want to focus on your business logic rather than focus on upgrading dependencies or debugging production issues because your dev and test environments ended-up being different than your production one.

Great and why not have more CI tools in the elixir standard lib, by that i mean something like mix format --check-formatted . That s a great tool.

Mix doesn’t use a dependent library’s lock file when resolving package versions though, right? Just the constraints in its deps. So the lock file is just a tool for the developer of the library. I think this systematically applies the approach advocated, rather than contradicting it.

But shouldn t we be using stuff like Docker/Ansible/Vagrant for all that?

No, it doesn’t. But I was talking about the top-level. Imagine I remove the mix.lock from Ecto. Now a person who is trying to contribute to Ecto for the first time may clone it and get a bad dependency which may be the source of confusion.

These do not solve the same problem. Those tools do not resolve your Elixir library dependencies when you build your application. You deploy your built application with those sort of tools.

And having reproducible builds has nothing to do with startups or legacy code. It has to do with not wanting stuff to break for unexplainable reasons. Frankly, I’d consider it unprofessional to deploy whatever random code resolves that day to production.