We don’t disagree at all, I think I didn’t express myself well to begin with. Mix already implements the part I think is important, which is that lock files in a library shouldn’t constrain the resolution of dependencies when that library is used in someone else’s project. I agree with having a lock file in the repo, this way other developers on the project have a resolution set known to work when they begin development.
jeremyjh
homologist
You can build a dev env on your server and store it, and then ship it to your dev team with docker/vagrant. How dependencies could resolve differently then? And that might be where I lost some of you. I was assuming that you CAN clone you environment and make it available for your team(I hope a fresh start up can do that). And from that prospective why would you lock?
Yes having legacy code is a major source of locking stuff, like when you have java dependencies… And I m not saying the only cause but a major cause.(Why security sofware is never up to date?)
0
LostKobrakai
Shipping a docker/vagrant image with dependencies already included is the super expensive version of locking dependencies. If you’re not including dependencies in those images when you’re back to square one: Either include the lock file so everyone gets the same versions when using the image or don’t included it and risk that dependencies drift and cause issues.
That’s why the issue is really orthogonal to using docker or vagrant. Both neither prevent nor solve the issue.
In an ideal world you could just depend on a mayor version of a library instead of locking to a specific one, but people make errors, multiple dependencies might conflict and cause issues the individual maintainer couldn’t have known, …. The real world just isn’t that perfect.
1
jeremyjh
A lock file can be versioned in your source repository. This way you know when every change was made. When a problem is found, you can git blame to see what the change was supposed to address in the first place, etc. In general, you want all of your code managed this way, including your dockerfiles ansible scripts etc. Much of the success of docker, and much of the benefit of “infrastructure as code” relates to the fact that you can manage it this way. The built images are managed strictly as a deployment concern, not as a development tool.
2