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

Re: Pipenv: promises a lot, delivers very little

#31

Post by hyperion2010 » Wed, Dec 05, 2018, 10:18 PM UTC

Allow me to reproduce a comment that I made in /r/programming last week on this topic.

I use pipenv in production and testing to simplify deployment on systems that don't natively support python 3.6+. When it works it is great. When it fails, or when the cli options fight each other and try to be smart but instead for a circular firing squad it is one of the most insanity inducing pieces of software I have ever used. Pipenv release have repeatedly broken CI builds for me for the past 3 months. I was so pissed with how bad it was about 9 months ago that I actually gave up trying to use it on my development machine and learned how to write gentoo ebuilds. On reflection it seems like the perfect tool for python -- if you stay on the happy path and only use it in BDFL APPROVED ways then it can be great, be woe to the fool who wanders from the light into madness.

Re: Pipenv: promises a lot, delivers very little

#32

Post by sametmax » Wed, Dec 05, 2018, 10:19 PM UTC

pmoriarty wrote: post #11

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?

Peotry does not handle the virtualenv at all. It deals only with the dependancy file and packaging.

So you usually couple it without something else. I use "pew".

I wish a tool would merge both.

Re: Pipenv: promises a lot, delivers very little

#33

Post by X-Istence » Wed, Dec 05, 2018, 10:21 PM UTC

greysteil wrote: post #29

pselbert wrote: 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.

Tools such as Poetry and others expect that information to be available on PyPI, so long as you are using a newer version of setup tools and use twine to upload.

Re: Pipenv: promises a lot, delivers very little

#34

Post by ausjke » Wed, Dec 05, 2018, 10:22 PM UTC

I use pipenv for the past year, there are some hiccups but overall I found it works well for my cases. I only need store Pipfile to my git repo and after 'pipenv shell' things just worked as expected for me.

Re: Pipenv: promises a lot, delivers very little

#35

Post by sdispater » Wed, Dec 05, 2018, 10:22 PM UTC

sametmax wrote: post #32

pmoriarty wrote: post #11

Earlier quoted context omitted.

"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?

Peotry does not handle the virtualenv at all. It deals only with the dependancy file and packaging. So you usually couple it without something else. I use "pew". I wish a tool would merge both.

What do you mean?

Poetry does create virtualenvs to install dependencies on a per-project basis.

Re: Pipenv: promises a lot, delivers very little

#36

Post by heavenlyblue » Wed, Dec 05, 2018, 10:23 PM UTC

Townley wrote: post #19

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 wh…

What I don't really get is this: why can't you just prepend the virtualenv to the PATH and be good with it?

That is only required obviously if you're using bash scripts which can't be directed to an actual python binary.

Re: Pipenv: promises a lot, delivers very little

#37

Post by erikb » Wed, Dec 05, 2018, 10:25 PM UTC

sigmonsays wrote: post #3

This article is just a reminder that it may be impossible to fix the nightmare that is pythons packaging system. I'll save the python rant but this kind of software just further fragments and damages pythons reputation.

Honestly it's a nightmare in every language. And I found in comparison to most other languages I've worked with (Java, Ruby, PHP, Golang) I actually feel it's done quite well.

It's a super complex topic, it needs leadership support so that you can get a reasonable percentage of the community to drill down on one solution instead of having 4-5 competing ones, but it also needs a lot of in-depth insights, which is kind of opposite to leadership which requires a top-down view.

Re: Pipenv: promises a lot, delivers very little

#38

Post by epage » Wed, Dec 05, 2018, 10:26 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…

Poetry is one of the few things that gives me hope about the mess of python packaging.

It is also great to see the author is very responsive.

My only concern is the lack of integrated "toolchain" management (what versxon of python to use, something like rustup) that is cross platform.

Re: Pipenv: promises a lot, delivers very little

#39

Post by coleifer » Wed, Dec 05, 2018, 10:27 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.

`pip freeze > requirements.txt`

Re: Pipenv: promises a lot, delivers very little

#40

Post by sametmax » Wed, Dec 05, 2018, 10:27 PM UTC

sdispater wrote: post #35

sametmax wrote: post #32

Earlier quoted context omitted.

Peotry does not handle the virtualenv at all. It deals only with the dependancy file and packaging. So you usually couple it without something else. I use "pew". I wish a tool would merge both.

What do you mean? Poetry does create virtualenvs to install dependencies on a per-project basis.

Sorry, I got confused with another tool.