Live data from Hacker News

Pipenv: promises a lot, delivers very little

chriswarrick.com

21–30 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#21
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.

With pip for instance, it often happens that a transitive dependency gets updated inadvertently breaking your code. This follows from the assumption that all packages follow semantic versioning perfectly and keep backward compatibility where they should. This is not the case in practice and experience has shown it is unrealistic to have that assumption. A better way is to rely on exact versions of packages (up to a single bit) and not on semantic versioning.

Re: Pipenv: promises a lot, delivers very little

#22
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.

Have you ever used any other mature dependency management tool? Leiningen, Cargo, Composer, Yarn, just to name a few. All of them are light-years ahead of anything Python provides, which is sad.

Re: Pipenv: promises a lot, delivers very little

#23
The problem, in my view, is not that pipenv is buggy or flawed or changes too rapidly. The problem is that it was hyped-up with overblown promises and marketing and sycophantic testimonials. The author of the project describes this himself in his "letter to r/python":

> ...my fame, while certainly categorized under “cult of personality” is not necessarily accidental. It’s called marketing. I worked very hard at becoming well known within the Python community, and toiled away at it for years.

I see this as the real issue, which led to premature adoption of a tool that wasn't stable, and the subsequent backlash.

Also, I have been using virtualenv for years and if I want to freeze my dependencies, running `pip freeze > requirements.txt` is sufficient for me.

Re: Pipenv: promises a lot, delivers very little

#24
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 also am a big fan of pyenv

I like the idea of pyenv, but in practice I find it to be pretty buggy (e.g. failing when installing older versions of python due to openssl build issues). I kind of wish it had some competition.

Re: Pipenv: promises a lot, delivers very little

#25
post #5

Don't forget to pin pipenv itself, each dot release breaks something

Oh, they don't do dot releases anymore, its "CalVer" [1] - aka. Calendar Versioning, aka. release when we feel like it. And why did they do this:

> We just switched the project over to calver, with the explicit purpose of preventing [Kenneht Reitz] from making more than one release a day

[1] https://calver.org/ [2] http://journal.kennethreitz.org/entry/r-python (Ctrl-F 'calver')

Re: Pipenv: promises a lot, delivers very little

#26

Pipenv is a really interesting development for Python, and I'm glad that someone was working to improve dependency locking for Python. However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth a…

Sometimes, improvements don't happen in a straight line.

There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release.

If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are committed and doing a great job.

Re: Pipenv: promises a lot, delivers very little

#28
I rarely comment here on hackernews. I've also seen several flame wars over pipenv. I also believe that python packaging and pinning is nothing but a mess. Recently I started using Pipenv and suddenly I've been having horrific issues with python to the point of me almost giving up on the language itself. I believe the issue is a mix of Pipenv, Pip and Debian. I don't have full scope view of the issue yet but without evidence I believe the issue is how Debian uses Pip at the system level, and in pip 9+ an API used by Debian changed. Pipenv seems to greedly somehow upgrade my pip and thusly hoses everything and I find myself reinstalling everything. All three are making me consider making changes to my entire stack and setup that I've been using daily for the past 5 years on many many systems.

In addition when/if I have time I'll further debug and attempt at PRs and issues to help.

Re: Pipenv: promises a lot, delivers very little

#29
post #6

Our organization uses four primary languages (Ruby, Python, JS and Elixir). The package management situation for Python is by far the weakest. We’ve been using Pipenv, but it is atrociously slow and flawed at dependency resolution. An alternative is extremely welcome, E.g. Poetry which was mentioned above.

FWIW, resolution in Python is significantly harder than for Ruby, JS or Elixir because it requires cloning down each dependency. To really speed it up, what's needed is a registry API that provides all of the details for resolution. That's much harder for Python because of the legacy of setup.py, which allows version resolution to depend on arbitrary system considerations.

Re: Pipenv: promises a lot, delivers very little

#30
post #5

Don't forget to pin pipenv itself, each dot release breaks something

Oh, they don't do dot releases anymore, its "CalVer" [1] - aka. Calendar Versioning, aka. release when we feel like it. And why did they do this: > We just switched the project over to calver, with the explicit purpose of preventing [Kenneht Reitz] from making more than one release a day [1] https://calver.org/ [2] http://journal.kennethreitz.org/entry/r-python (Ctrl-F 'calver')

Don't worry, each CalVer release still breaks things.
Post reply on HN