51–60 of 64 posts
Any insights on why not use conda instead?
Earlier quoted context omitted.
Poetry is basically perfect, it does what it says and has no surprises. Well, except one thing: If I do `poetry update `, it starts upgrading other packages as well. I'm not sure what that's about...
As long as you install it correctly, which can be difficult on systems where python2 is the default.
Earlier quoted context omitted.
pip freeze only pins the version of direct, not transitive dependencies. Meaning you don't get deterministic builds.
Not so. I use pip freeze to manage my dependencies, including all transitive dependencies, and my builds are deterministic.
Worth noting that Sébastien Eustace is an author of the provisional PEP 621: "Storing project metadata in pyproject.toml"
Earlier quoted context omitted.
I like that pipenv also handles virtualenv creation, but I too moved my projects to Poetry after all of the various Pipenv-maintainer fiascos
By default, poetry automatically creates virtualenvs for you. Though you can override that behavior in your local or global poetry config.
With Poetry, the venv is created with whatever version of python that Poetry was installed with. So if you (like me) follow the setup guide on macOS, Poetry will always create python 2.7 virtualenvs until you uninstall it and re-install it under python 3.X. Annoying.
Earlier quoted context omitted.
Not so. I use pip freeze to manage my dependencies, including all transitive dependencies, and my builds are deterministic.
How do you include checksums in your freeze to catch when the package changes on the pypi server using only pip?
What does this tool provide over an in-project .venv/ directory created by venv and populated by pip from an etc/pip/requirement.txt file containing all the packages by version? There seems to be a lot of activity in this area for a seemingly solved problem. Having solved it, people appear to wish to expand the problem to something bigger (such as multiple interpreter versions, for example) I believe the most-common…
Earlier quoted context omitted.
By default, poetry automatically creates virtualenvs for you. Though you can override that behavior in your local or global poetry config.
Oops. What I meant is, Pipenv manages python versions for you. You tell it what version of python your project uses, and pipenv will make sure to create the venv using that version of python. Great! Solves managing python versions. With Poetry, the venv is created with whatever version of python that Poetry was installed with. So if you (like me) follow the setup guide on macOS, Poetry will always create python 2.7 v…
I'm not sure I completely love that behavior; it would be nice if it would default toward trying to use the minimum supported version, even if the currently active one is compatible. But I guess that wouldn't do anything that tox couldn't do better.
You can also explicitly tell it what version to use for a project with a command like `poetry env 3.8`.