41–50 of 64 posts
About a year ago or so I moved to pyenv and poetry. I have used python for over 10 years it was a game changer. I recommend this guide if your still using pip and venv. https://cjolowicz.github.io/posts/hypermodern-python-01-setu...
EW. Avoid. For the tenth time in these comments, use poetry. It's a real shame PyPA endorsed this to be honest, I hope that can be reversed at some point in the future.
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...
Earlier quoted context omitted.
What do you mean? If you run pip freeze inside a venv it will print every user-installed module and their dependencies. When installing them in a new venv as a requirements file, you end up with the exact same set of modules.
Agree. Works fine for me exactly as you describe. I don't understand why people furiously want more than this for the common case. (Choose python version, create .venv/ directory, install packages, use installed .venv/ and do work.)
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.
Seeing all the comments in this thread that people have had bad experiences with pipenv, this contrasts with my own experience which has been pretty good. How has pipenv failed for everyone? Gonna take a look at poetry, but would love to hear what problems people have had with pipenv?
2. When Airflow added a dependency choice (based on licences) the setup script required an ENV var choosing one to be set, pipenv swallowed the stdout output and dumped a Pip stacktrace that didn't help diagnose the issue.
3. Mysterious bugs on new pipenv releases that usually manifested as a Pip stack-trace or setuptools stack-trace.
4. Sometimes the bugs were installed Pip version dependent, which made replication hard.
There was other stuff, but can't quite remember off the top of my head.
But yeah, we spent a lot of time trying to figure out why pipenv had broken again. Poetry has been a breeze in comparison.
About a year ago or so I moved to pyenv and poetry. I have used python for over 10 years it was a game changer. I recommend this guide if your still using pip and venv. https://cjolowicz.github.io/posts/hypermodern-python-01-setu...
Is this not applicable to Windows? The article mentions Unix, Linux, and Mac. Sorry for the n00b question; I'm just an amateur Python data analyst.
Earlier quoted context omitted.
pip freeze only pins the version of direct, not transitive dependencies. Meaning you don't get deterministic builds.
What do you mean? If you run pip freeze inside a venv it will print every user-installed module and their dependencies. When installing them in a new venv as a requirements file, you end up with the exact same set of modules.
Earlier quoted context omitted.
Isn’t this what pip freeze is for?
pip freeze only pins the version of direct, not transitive dependencies. Meaning you don't get deterministic builds.
Earlier quoted context omitted.
What do you mean? If you run pip freeze inside a venv it will print every user-installed module and their dependencies. When installing them in a new venv as a requirements file, you end up with the exact same set of modules.
Issues start occurring when you, for example, delete dependencies because with pip freeze you cannot ensure that you have deleted their dependencies also. The most common solution to this (that poetry and pipenv use) is to provide a lockfile to track transitive dependencies and their versions, without that (except for manually curating your dependencies) you can't ensure that you get a reproducible environment.
Adding/removing top level dependencies over time does require the use of two files (the top level requirements and the frozen/locked requirements which lists everything). Or you can list the top level requirements in setup.py and let requirements.txt be the lockfile. It would be nice if pip managed this lockfile automatically, but I'm not really interested in adding any of these newer tools to my toolchain just to manage a lockfile.
There are many packaging and distribution frustrations in Python, I don't think pip's management of dependency lists is one of them
Earlier quoted context omitted.
Agree. Works fine for me exactly as you describe. I don't understand why people furiously want more than this for the common case. (Choose python version, create .venv/ directory, install packages, use installed .venv/ and do work.)
What happens when you use a different version of the same library that a dependency uses?
When multiple versions of the same library are allowed to coexist in different dependency trees there is less incentive to solve these conflicts and versions proliferate (see npm).
I'd much rather solve the occasional conflict (usually solved either by settling on some older version of both parent dependencies - and later advancing as possible - or just trying to fix it and send a patch upstream).