5 ms·

I still struggle to see the point with every project that starts out using pipenv. Python -m venv & activate & pip install -r requirements.txt works more often(

by nabdab 7y ago

I still struggle to see the point with every project that starts out using pipenv. Python -m venv & activate & pip install -r requirements.txt works more often(every time for me) and is faster. I have literally not once seen a project where the pipenv solution was better, but I’ve seen 12 where it straight up failed to install correctly and all others it was slower by a large factor. For me pipenvs only selling point is that some people don’t know about python -m venv.

cheez 7y ago
The only thing that pipenv does better is that it uses package hashes. This gives some confidence that you are really installing what you think you are. But I hate pipenv, so much.
djstein 7y ago
the main selling point was the simplicity + lock (which takes forever to generate), but since Pipenv barfs on itself again and again against "closed + will not reopen" issues and unsupported feature flags it's use becomes more of a pain
cheez 7y ago
Just learned about this: https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode https://pip.pypa.io/en/stable/reference/pip_install/#hash-ch...
lazzlazzlazz 7y ago
The fact that requirements.txt files are by-default version pegged is an absolute nightmare for people upgrading. It simply does NOT work for a serious, large project that you'd like to keep up to date as dependencies improve. It might seem like it works great for a new, tiny, short-lived project, or to inexperienced devs. The basic idea of pipenv, being able to resolve the dependency graph more cleanly and precisely, is far far far better - but there are still some usability improvements that leave something to be desired.
- scjody 7y ago
  pip-compile (part of https://pypi.org/project/pip-tools/ https://pypi.org/project/pip-tools/ ) provides a significantly better way to maintain a requirements.txt file: create a requirements.in that specifies only the things you care about, and pip-compile it into a requirements.txt with pinned versions. Then you can use pip-compile --upgrade to upgrade just some of the versions, unlike pipenv which wants you to upgrade everything, whether you're ready to or not.
mixmastamyk 7y ago
Most projects don't need either. I only use pipenv on a work project with a hundred dependencies, and venv on one other large side project. Everything else is installed with --user, especially dev tools like black and pyflakes. The user folder gets cleaned up every few years when you upgrade to a new version of python (rm ~/.local/lib/python3.5). Has worked fine for a decade or two, no conflicts. I think some folks get spooked at python packaging and overcompensate in response, but it's pretty easy to troubleshoot when you've learned how it works.
- pbecotte 7y ago
  This is only true in the limited case where you never have to share your code with anyone. If you want to share it, setting it up so others can get going without having to figure out which packages are missing is necessary. In that case, you should probably use that same tool yourself to make sure that your environment works the same as you expect others to use it.
  - mixmastamyk 7y ago
    Nope, share code all the time. That is what requirements.txt (and alternatives) are for. Where they install them is up to them.
vonseel 7y ago
Agreed. Pipenv only led to confusion and pain for me. Last time I tried to use it in a project led to not knowing what the heck to do once I wanted to in my dockerfile - do I install pipenv inside docker? what's the point of that? Is there a tool to convert this Pipfile to a requirements.txt file to use with plain 'ole pip or what? Quickly noticing my mistake in being driven to play with shiny, new toys, I went back to my old tried-and-true pip + virtualenv for local development and plain old pip inside docker. I think part of the drive around changes to Python packaging standards and tools has been inflated by a poor understanding and poor usage of existing tools. Take setup.py for example - nearly everything you read in Python pushes using a requirements.txt file in your project. Why not define your project as an installable package with its own hard requirements - that are defined in your setup.py - and leave the Pip requirements.txt strictly for additional development/test dependencies? Or, maybe better, put test requirements in tests_require? Nothing against Kenneth, but a big part of me wishes there were more anonymity in the open-source community. It's too easy for a single, well-known individual to come in and publicize <something> and everyone jumps on the <something> bandwagon without realizing that <other-thing> already exists, works well, and is an established standard.

by nabdab 7y ago

cheez 7y ago

The only thing that pipenv does better is that it uses package hashes. This gives some confidence that you are really installing what you think you are. But I hate pipenv, so much.

djstein 7y ago

the main selling point was the simplicity + lock (which takes forever to generate), but since Pipenv barfs on itself again and again against "closed + will not reopen" issues and unsupported feature flags it's use becomes more of a pain

cheez 7y ago

Just learned about this: https://pip.pypa.io/en/stable/reference/pip_install/#hash-checking-mode https://pip.pypa.io/en/stable/reference/pip_install/#hash-ch...

lazzlazzlazz 7y ago

The fact that requirements.txt files are by-default version pegged is an absolute nightmare for people upgrading. It simply does NOT work for a serious, large project that you'd like to keep up to date as dependencies improve. It might seem like it works great for a new, tiny, short-lived project, or to inexperienced devs. The basic idea of pipenv, being able to resolve the dependency graph more cleanly and precisely, is far far far better - but there are still some usability improvements that leave something to be desired.

scjody 7y ago
pip-compile (part of https://pypi.org/project/pip-tools/ https://pypi.org/project/pip-tools/ ) provides a significantly better way to maintain a requirements.txt file: create a requirements.in that specifies only the things you care about, and pip-compile it into a requirements.txt with pinned versions. Then you can use pip-compile --upgrade to upgrade just some of the versions, unlike pipenv which wants you to upgrade everything, whether you're ready to or not.

mixmastamyk 7y ago

Most projects don't need either. I only use pipenv on a work project with a hundred dependencies, and venv on one other large side project. Everything else is installed with --user, especially dev tools like black and pyflakes. The user folder gets cleaned up every few years when you upgrade to a new version of python (rm ~/.local/lib/python3.5). Has worked fine for a decade or two, no conflicts. I think some folks get spooked at python packaging and overcompensate in response, but it's pretty easy to troubleshoot when you've learned how it works.

pbecotte 7y ago
This is only true in the limited case where you never have to share your code with anyone. If you want to share it, setting it up so others can get going without having to figure out which packages are missing is necessary. In that case, you should probably use that same tool yourself to make sure that your environment works the same as you expect others to use it.
- mixmastamyk 7y ago
  Nope, share code all the time. That is what requirements.txt (and alternatives) are for. Where they install them is up to them.

vonseel 7y ago

Agreed. Pipenv only led to confusion and pain for me. Last time I tried to use it in a project led to not knowing what the heck to do once I wanted to in my dockerfile - do I install pipenv inside docker? what's the point of that? Is there a tool to convert this Pipfile to a requirements.txt file to use with plain 'ole pip or what? Quickly noticing my mistake in being driven to play with shiny, new toys, I went back to my old tried-and-true pip + virtualenv for local development and plain old pip inside docker. I think part of the drive around changes to Python packaging standards and tools has been inflated by a poor understanding and poor usage of existing tools. Take setup.py for example - nearly everything you read in Python pushes using a requirements.txt file in your project. Why not define your project as an installable package with its own hard requirements - that are defined in your setup.py - and leave the Pip requirements.txt strictly for additional development/test dependencies? Or, maybe better, put test requirements in tests_require? Nothing against Kenneth, but a big part of me wishes there were more anonymity in the open-source community. It's too easy for a single, well-known individual to come in and publicize <something> and everyone jumps on the <something> bandwagon without realizing that <other-thing> already exists, works well, and is an established standard.