Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pipenv: promises a lot, delivers very little

chriswarrick.com

Post reply on HN
Print view View original

71–80 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#71

Post by icebraining »

wirrbel wrote: post #62
umvi wrote: post #54

I hate python package/dependency/virtualenv management so much. Even JavaScript is preferable. I find npm very easy to wrap my head around. I do npm install ___ and it does a lookup in its repository and downloads it and its dependencies to node_modules. If I want to start fresh, I simply delete node_modules. Everything else "just works" when I invoke node myapp.js. Punto e basta. pipenv masquarades as the same thing…

Basically it seems you are lacking only two shell commands. virtualenv venv . venv/bin/activate Then everything works with pip pip install numpy I actually prefer the pipenv way (or the virtualenvwrapper way) of putting virtualenvs into a dedicated location, so that I can wipe them off the hard disk if I want to free some space. The real interesting and occasionally bothering point on managing your virtualenv is reso…

At a previous job, we used an even simpler solution: just download everything to a directory (called "deps") with

    pip install --target deps -r requirements.txt
Then running the application with

    PYTHONPATH=deps python myapp.py
This was also simple to integrate with service supervisors, since most make it easy to configure a environment variable.

Re: Pipenv: promises a lot, delivers very little

#72

Post by wuliwong »

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.

I've never really delved deeply into package management. I've been using ruby for a while and using rbenv has made it pretty painless for a while.

I've been using pipenv on my local machine but then switched to virtualenv in my ec2 deployments (because all the tutorials used it).

What makes it easier for ruby? Is there just this "registry API" that has gained enough traction that everyone uses it?

Re: Pipenv: promises a lot, delivers very little

#73

Post by pseudalopex »

heavenlyblue wrote: post #36
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.

"activate" prevents accidentally nesting environments. It also changes the prompt to show which one is active. Running "deactivate" is easier than changing the environment variables back yourself.

Re: Pipenv: promises a lot, delivers very little

#74

Post by icebraining »

adaszko wrote: post #21
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.

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

How would you updated something inadvertently?

Re: Pipenv: promises a lot, delivers very little

#75

Post by Twirrim »

tutuca wrote: post #66
bitfhacker wrote: post #15

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?

For me it was the promise to be able to maintain my dependencies up to date and avoid manually handling configuration files. Working in a team it is often useful to have your versions "pinned" down so you have a reproducible environment regardless of upstream backwards compatibility policy (just to name one example). The Pipfile + Pifile.lock combo seemed right for the task. Creating virtualenv was a nice plus.

What was wrong with requirements.txt? We heavily use virtualenvs and just pin package versions there. I've yet to see it fail.

Re: Pipenv: promises a lot, delivers very little

#76

Post by gizmo385 »

scrollaway wrote: post #50
sprt wrote: post #44

Earlier quoted context omitted.

Pipenv is designed solely for packaging applications, per the maintainers' admission. It's not suited for libraries and is not designed to be. If you want to replace pip, you should have a look at Poetry.

> It's not suited for libraries and is not designed to be. That's kind of the problem. Why on earth are libraries and apps getting a different treatment? The JS ecosystem manages to have one tool for apps and libraries. One too for installing and publishing. All of it with lockfile support, workspace/"virtualenv" support, etc. And somehow, it's not confusing. Adding one more tool to the stack is a really funky step f…

And it isn't only Javascript that manages to have a single tool for this. Clojure has a single tool. Java has a single tool. Rust has a single tool.

This is a solved problem across a variety of popular and mainstream programming languages. I don't mean to suggest that the problem isn't complicated, but this isn't a problem that doesn't have a wealth of previously written solutions to look at for inspiration.

Re: Pipenv: promises a lot, delivers very little

#77

Post by luhn »

The one thing about pipenv that prevents me from using it in more projects is that it refuses to not upgrate a dependency. If I install or upgrade a dependency, every dependency is upgraded. (I'm not sure what `--keep-outdated` is supposed to do, because it definitely does not keep outdated dependencies.) First of all, it's surprising and unpredictable. (Why would `pipenv upgrade requests` upgrade boto3?) It also prevents me from controlling change (and therefore controlling risk). I'm responsible for everything that gets deployed, so when I upgrade a dependency it is deliberate, isolated, and well-tested. I can't do that with pipenv.

I understand that they want to encourage keeping dependencies up-to-date, but I think the proper approach to this is npm's, where it informs me about outdated packages, but lets me do what I will with that information.

So, for the moment, I'm still in the dark ages of manually pinning everything into `requirements.txt`.

Re: Pipenv: promises a lot, delivers very little

#78

Post by chatmasta »

wirrbel wrote: post #62
umvi wrote: post #54

I hate python package/dependency/virtualenv management so much. Even JavaScript is preferable. I find npm very easy to wrap my head around. I do npm install ___ and it does a lookup in its repository and downloads it and its dependencies to node_modules. If I want to start fresh, I simply delete node_modules. Everything else "just works" when I invoke node myapp.js. Punto e basta. pipenv masquarades as the same thing…

Basically it seems you are lacking only two shell commands. virtualenv venv . venv/bin/activate Then everything works with pip pip install numpy I actually prefer the pipenv way (or the virtualenvwrapper way) of putting virtualenvs into a dedicated location, so that I can wipe them off the hard disk if I want to free some space. The real interesting and occasionally bothering point on managing your virtualenv is reso…

This doesn’t address his problem of dependencies being “halfway across my computer.”

Re: Pipenv: promises a lot, delivers very little

#79

Post by greysteil »

luhn wrote: post #77

The one thing about pipenv that prevents me from using it in more projects is that it refuses to not upgrate a dependency. If I install or upgrade a dependency, every dependency is upgraded. (I'm not sure what `--keep-outdated` is supposed to do, because it definitely does not keep outdated dependencies.) First of all, it's surprising and unpredictable. (Why would `pipenv upgrade requests` upgrade boto3?) It also pre…

This is about to get better - check out https://github.com/pypa/pipenv/pull/3304.

Re: Pipenv: promises a lot, delivers very little

#80

Post by scrollaway »

sametmax wrote: post #68
legostormtroopr wrote: post #4

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…

I'm very glad we have the wheel and ensurepip now. Yet, I think PyPA has not been taking the best decisions regarding Python packaging. Your Kenneth story is not the only "weird event" in their history. E.G: Did you know that we don't need "pyproject.toml" at all ? That there is already a production ready plain text standard to replace setup.py ? Did you know that this standard has been perfectly working for TWO YEAR…

I love setup.cfg, I've used it for years and indeed pyproject.toml is useless given that setup.cfg has existed for frickin ever at this point (and is supported by a multitude of tools). TOML is nice but its support isn't even in the stdlib which makes it very awkward to use for a core file like that.

Here are some examples of my libs/apps using it in the real world, if someone needs references for how to use setup.cfg with an empty or near-empty setup.py:

https://github.com/jleclanche/python-bna/blob/master/setup.c...

https://github.com/dj-stripe/dj-stripe/blob/master/setup.cfg

https://github.com/jazzband/django-oauth-toolkit/blob/master...

https://github.com/jazzband/django-push-notifications/blob/m...

Edit: I see you mention attr: src.__version__. I personally prefer doing it the other way around, with the version defined in setup.cfg and a pkg_resources snippet in __init__.py (https://github.com/HearthSim/python-hearthstone/blob/master/...).

To be honest I wish __version__ were automatically defined like that (but more reliably). Do you know if this was discussed in a PEP?

Post reply on HN