Re:Pipenv: Promises a Lot, Delivers Little (2020)
by Hackbraten on Saturday July 16, 2022 @10:13AM
(#32118320)
> That's a feature, you should be using the latest minor/patch release when developing.
You’re not wrong, but developers still need precise control about which version is pinned so they have a chance to figure out whether a bug is in their code or a regression in a dependency.
> If a dependency is constantly breaking on minor/patch releases you shouldn't be using it.
A more common example would be a dependency of decent quality, but there will still be bugs because there’s no such thing as bug-free software.
And when the inevitable issue comes up, it’s super useful to have a switch that lets you pin down the regression and helps you figure out whether it’s on you or on the upstream project to fix the issue.
> Please don't lock your dependencies to specific minor/patch versions
Even if you allow a version range of "*" in your dependency file, it may still be a good practice for your app to have the resolved version number pinned in a dependency lock file, and even commit that lock file to version control.
> Especially when you're writing a library. If you're locking to anything other than a major release or a minimum minor/patch revision when producing a library things have gone very wrong.
You’re referring to the dependency file, not the dependency lock file, right? I couldn’t agree more.
At the same time, it may still make sense for some libraries to have a lock file during the development process, and even commit that lock file to version control. You just can’t include that lock file in your release.
You’re not wrong, but developers still need precise control about which version is pinned so they have a chance to figure out whether a bug is in their code or a regression in a dependency.
> If a dependency is constantly breaking on minor/patch releases you shouldn't be using it.
A more common example would be a dependency of decent quality, but there will still be bugs because there’s no such thing as bug-free software. And when the inevitable issue comes up, it’s super useful to have a switch that lets you pin down the regression and helps you figure out whether it’s on you or on the upstream project to fix the issue.
> Please don't lock your dependencies to specific minor/patch versions
Even if you allow a version range of "*" in your dependency file, it may still be a good practice for your app to have the resolved version number pinned in a dependency lock file, and even commit that lock file to version control.
> Especially when you're writing a library. If you're locking to anything other than a major release or a minimum minor/patch revision when producing a library things have gone very wrong.
You’re referring to the dependency file, not the dependency lock file, right? I couldn’t agree more. At the same time, it may still make sense for some libraries to have a lock file during the development process, and even commit that lock file to version control. You just can’t include that lock file in your release.