3 ms·
why poetry over pyenv-virtualenv?
by petulla 5y ago
why poetry over pyenv-virtualenv?
- EamonnMR 5y agoWhat poetry replaces is pip and requirements.txt. Our team had a lively discussion about this, but here are some good reasons: * Keep test frameworks out of production (in case they've busted something; the two points below can happen to test libraries too.) * pip recently changed the way it's resolver works[1], breaking numerous projects. Yeah yeah, it's a major version bump, but lots of containers and environments installed pip latest just sort of assuming that it would always handle requirements.txt the same way. With that contract broken, now using pip directly isn't a non-decision anymore. * Locking specific versions of dependencies can you roll back Bad News in production. Let's say you have a project with library A which has dependency B. If A asks for the latest version of B, you can be in a situation where a new version of B breaks your project and you won't know about it until you do a release _and_ if you try to roll back you'll still be in trouble. We recently had to deal with a similar issue and had to fall back on an older container until we could figure it out. [1] https://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.html?m=1 https://pyfound.blogspot.com/2020/11/pip-20-3-new-resolver.h...
- mvanbaak 5y agopip is not to blame for the above points. * if your code is under src/ and your tests under test/, you use a requirements-test (or better, tox.ini) your tests including the dependencies like pytest dont end up in a wheel * if a container depends on 'latest' and not some semver major number, it's 100% the containers fault when they blindly update to a new major version * 'pip freeze' is your friend
- EamonnMR 5y agoAgreed, Pip isn't to blame, treating `pip install -r requirements.txt` as one's sole dependency management is. You can choose to build your own dependency management practice around pip, or use one someone else has already created. I think that it is easier to get a team on the same page with something like Poetry, especially if they're used to bundler or npm. You're right about the docker containers as well, but upstream does what it wants and downstream has a strong tendency to not mess with upstream's choices.
- d4rkp4ttern 5y agoIndeed, why Poetry? Poetry At first glance looks and feels good (and I even used it for a while) until you hit a weird bug and find that’s it’s one of the 989 open issues https://github.com/python-poetry/poetry/issues https://github.com/python-poetry/poetry/issues So it’s back to plain old venv + requirements.txt for me
- vorticalbox 5y agopip has 886 open issues[0], I am not sure the issue total is much of a measuring stick in this case. my problem is that venv + requirements.txt is just plain simpler to use. [0] https://github.com/pypa/pip/issues https://github.com/pypa/pip/issues
- coffeefirst 5y agoPoetry has lock files, so installs are always the exact same version of everything. I've found this is almost great, but when it breaks down, perhaps because two packages request a transitive dependency in different ways, or if the resolver really wants to install a new version of something that won't compile on your system, it's a giant pain and sometimes impossible to work around. These days I just use pip with venv unless I have a good reason not to.