Pipenv: promises a lot, delivers very little • Hacker News Board

Re: Pipenv: promises a lot, delivers very little

#11

Post by pmoriarty » Wed, Dec 05, 2018, 9:56 PM UTC

dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

"I was sorely disappointed with pipenv"

Can you flesh this out a little bit? What in particular were you disappointed with pipenv?

How does poetry do a better job?

Re: Pipenv: promises a lot, delivers very little

#12

Post by sjburt » Wed, Dec 05, 2018, 9:58 PM UTC

Apreche wrote: post #9

I've used virtualenv, pipenv, pyenv, venv, etc. What the hell is the difference? All that I have used have worked pretty much exactly the same as the others. All work just fine. I've never had a problem. I just use virtualenv since it's the oldest. I see no more reason to switch or try other options as long as it continues to deliver.

Yeah, the problems with python packaging can not be fixed by any tool. There is simply no way to determine the dependencies of a python package without downloading it and all its dependencies. And, no accurate way without actually interpreting setup.py.

Re: Pipenv: promises a lot, delivers very little

#13

Post by pmoriarty » Wed, Dec 05, 2018, 9:58 PM UTC

Apreche wrote: post #9

I've used virtualenv, pipenv, pyenv, venv, etc. What the hell is the difference? All that I have used have worked pretty much exactly the same as the others. All work just fine. I've never had a problem. I just use virtualenv since it's the oldest. I see no more reason to switch or try other options as long as it continues to deliver.

"What the hell is the difference?"

One of the big selling points of pipenv is that you can pin the versions of the packages you use and their dependencies.

None of the others do this, afaik.

Re: Pipenv: promises a lot, delivers very little

#14

Post by lvh » Wed, Dec 05, 2018, 10:00 PM UTC

The article doesn't mention pyenv, which I've used to great effect. It does pretty much everything I want, including having multiple environments active at once (so that tools that want to do their own virtualenv management, like tox, can find a python2.7, python3.5, python3.6, python3.7, pypy2... in PATH) and automatically activating a virtual environment when I go into a particular directory.

For a project to be easy for me to use, it doesn't need to do anything fancy to accommodate me: 1) 2 or 3 or both? 2) a setup.py or a requirements.txt. I basically always `pyenv virtualenv 3.7.1 $PROJECT && pyenv local $PROJECT` and then more or less never worry about this problem again.

When I need to _produce_ a pinned set of dependencies, it's all just pip + virtualenv so pip freeze works just fine.

The killer feature of pipenv is allegedly pinning but this has never made sense to me. Maybe I just don't understand it? But pyenv makes highly segregated environments easy, so as long as each project has an internally set of environments, everything is A-OK.

Re: Pipenv: promises a lot, delivers very little

#15

Post by bitfhacker » Wed, Dec 05, 2018, 10:00 PM UTC

I never used pipenv but I use virtualenv+pip. Pip always resolved well all dependencies for me, so... What are the advantages of pipenv over virtualenv+pip?

Re: Pipenv: promises a lot, delivers very little

#16

Post by sweatersong » Wed, Dec 05, 2018, 10:01 PM UTC

dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

I'm looking into transitioning to poetry from Pipenv...my main gripes with Pipenv are 1) pyenv integration is cludgey and 2) "hard" conflicts between packages are unresolveable in pipenv and means you cannot lock your environment.

As far as #2 is concerned, does poetry allow you "ignore" or change subdependency requirements for specific packages a la maven?

Re: Pipenv: promises a lot, delivers very little

#17

Post by lvh » Wed, Dec 05, 2018, 10:02 PM UTC

dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

The pyenv-virtualenv extension makes all of the pyenv magic work for environments (as in virtualenvs) too.

Re: Pipenv: promises a lot, delivers very little

#18

Post by bitfhacker » Wed, Dec 05, 2018, 10:03 PM UTC

pmoriarty wrote: post #13

Apreche wrote: post #9

I've used virtualenv, pipenv, pyenv, venv, etc. What the hell is the difference? All that I have used have worked pretty much exactly the same as the others. All work just fine. I've never had a problem. I just use virtualenv since it's the oldest. I see no more reason to switch or try other options as long as it continues to deliver.

"What the hell is the difference?" One of the big selling points of pipenv is that you can pin the versions of the packages you use and their dependencies. None of the others do this, afaik.

With pip you can: pip install package==version

Re: Pipenv: promises a lot, delivers very little

#19

Post by Townley » Wed, Dec 05, 2018, 10:04 PM UTC

Curious about one criticism in particular:

  I can run pipenv shell to get a new shell which runs the activate script by default, giving you the worst of both worlds when it comes to virtualenv activation: the unwieldiness of a new shell, and the activate script, which the proponents of the shell spawning dislike.

In a project that just uses pip + a virtual environment, I'm used to activating the virtual environment when I want to run a command.

Why is `pipenv shell` any worse than that? What do "proponents of shell spawning" dislike about the activate command?

Re: Pipenv: promises a lot, delivers very little

#20

Post by openbasic » Wed, Dec 05, 2018, 10:04 PM UTC

dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

Does poetry create a local vendor folder like "node_modules" or "vendor"?