Live data from Hacker News

Pipenv: Python Dev Workflow for Humans

pipenv.pypa.io

1–10 of 64 posts

Re: Pipenv: Python Dev Workflow for Humans

#2
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 case to be: 1 Choose python version and install on operating system., 2 create .venv/ directory. 3, install packages from package system (pip)., 4 freeze versions to local file. 5 use installed .venv/ and do work.

I've got some scripts I use for the above [1] -- must give it some TLC, and I don't understand why people furiously want more than this.

[1] https://github.com/gjvc/python-template-project

Re: Pipenv: Python Dev Workflow for Humans

#3
post #2

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…

The consensus among non-Python developers is that that is not good enough.

The problems are:

requirements.txt is way too flexible, so users want a lock file to freeze stuff in place.

You can use pip freeze to generate a sort-of-lockfile but it's more manual than tools like Cargo/npm/bundler which do it automatically. And more adhoc as to what you call it. Combined with needing to mange venvs and sourcing etc. people want a standard script that just figures out its context from the now standard "explicit requirements"/lockfile setup.

It doesn't handle versioning Python itself, which is expected of it for some reason, even though nobody cares that npm/Cargo/bundler don't version their languages.

Re: Pipenv: Python Dev Workflow for Humans

#5
post #2

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…

Agreed.

And the solution to the multiple interpreter versions problem should be orthogonal to venv like pyenv [1] instead of overlapping with venv like pipenv.

[1]: https://github.com/pyenv/pyenv

Re: Pipenv: Python Dev Workflow for Humans

#6
post #3
post #2

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…

The consensus among non-Python developers is that that is not good enough. The problems are: requirements.txt is way too flexible, so users want a lock file to freeze stuff in place. You can use pip freeze to generate a sort-of-lockfile but it's more manual than tools like Cargo/npm/bundler which do it automatically. And more adhoc as to what you call it. Combined with needing to mange venvs and sourcing etc. people…

The lock file shortcoming is better remedied by pip-tools [1] as recommended by a neighboring comment.

[1]: https://github.com/jazzband/pip-tools

Re: Pipenv: Python Dev Workflow for Humans

#7
post #3
post #2

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…

The consensus among non-Python developers is that that is not good enough. The problems are: requirements.txt is way too flexible, so users want a lock file to freeze stuff in place. You can use pip freeze to generate a sort-of-lockfile but it's more manual than tools like Cargo/npm/bundler which do it automatically. And more adhoc as to what you call it. Combined with needing to mange venvs and sourcing etc. people…

I felt the same way about only needing requirements.txt until I managed a project that needed to be compatible across many versions of python and some of it's dependencies were renamed from one version to another. I highly recommend you take a look at the hypermodern python guide https://cjolowicz.github.io/posts/hypermodern-python-01-setu...
Post reply on HN