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

121–130 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#121

Post by minikomi »

gizmo385 wrote: post #76
scrollaway wrote: post #50

Earlier quoted context omitted.

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

Clojure has two tools.. designed to be used as the single tool though.

Boot, and Lein. I'm partial to boot lately.

Re: Pipenv: promises a lot, delivers very little

#122

Post by murphy214 »

grumps wrote: post #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…

My goodness, thats like a PSA to never try pipenv at all if your running on a debian system, thanks for the heads up!

Re: Pipenv: promises a lot, delivers very little

#123

Post by pseudalopex »

rtpg wrote: post #111
scrollaway wrote: post #50

Earlier quoted context omitted.

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

libraries and apps _should_ get different treatment. A library often has to coexist with other unknown code (open world assumption), an application you're controlling is effectively existing in one specific universe: the one you define (closed world assumption). You wouldn't write your application to support 5 versions of Django, but you _probably_ would do so for a library. That said, I do basically agree about `pip…

An internal application can exist in one specific universe. Most of the time.

The "library" workflow works for applications too. Put your direct dependencies in setup.py. Build wheels of everything and upload them to an internal PyPI server. Pin everything in requirements.txt.

Re: Pipenv: promises a lot, delivers very little

#124

Post by circles_for-day »

greysteil wrote: post #26
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…

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

I just switched away today. It still sucks

Re: Pipenv: promises a lot, delivers very little

#125

Post by scrollaway »

pvg wrote: post #112
scrollaway wrote: post #50

Earlier quoted context omitted.

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

Pipenv keeps flouting itself That would be weird. Perhaps you mean 'flaunting'?

Yes, typo :)

Re: Pipenv: promises a lot, delivers very little

#126

Post by m_ke »

malcolmgreaves wrote: post #115
mlthoughts2018 wrote: post #70

People please stop engaging with pipenv and just use conda. Even critical arguments are mistakenly acting like pipenv deserves a seat at the table. Just don’t engage. It’s like the creationism of Python packaging.

I don't understand why this comment isn't higher! Honestly, using `conda` eliminates the pain of python dependency & environment management entirely. Clone a repo, do `conda env create` (from the project's `environment.yml`), then `source activate $ENV_NAME`. Straightforward. Easy. But most importantly, reliable!

It's great but can be a pain if you develop on a mac and try to replicate your env on linux because the env files are not portable.

The CLI can be confusing at times too, I always have to google how to create a new env or export it.

Re: Pipenv: promises a lot, delivers very little

#127

Post by pseudalopex »

sametmax wrote: post #86
pseudalopex wrote: post #81

Earlier quoted context omitted.

setup.cfg lets you configure setuptools with declarative syntax. pyproject.toml lets you replace setuptools with something else. The PEP explains why they didn't just reuse setup.cfg.[1] [1] https://www.python.org/dev/peps/pep-0518/#sticking-with-setu...

> The point of pyproject.toml is to allow other libraries to replace setuptools. This can be done with setup.cfg. Setuptools is only a backend supporting it. You can create other ones. Poetry and pipenv could support it in a week in their authors decided so. > The reasons for not using setup.cfg are explained in the PEP.[1] Those are not reasons, those are excuses. Let me quote it: >> There are two issues with setup.…

The "existing standard" is whatever configparser accepts. configparser is part of the standard library. Different versions accept different things. The setuptools documentation covers higher-level things like key names. That isn't what they're trying to standardize.

The last sentence you quoted explains why they picked "pyproject" instead of "setup". It isn't why they picked TOML.

Re: Pipenv: promises a lot, delivers very little

#128

Post by jazzyjackson »

icebraining wrote: post #71
wirrbel wrote: post #62

Earlier quoted context omitted.

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.

Making a note of this, didn't know about the target flag, thanks !

Re: Pipenv: promises a lot, delivers very little

#129

Post by metasyn »

We recently switched to using poetry over pip and virtual envs. All the additional tooling poetry provides is amazing - actual dependency resolution, script entry point, building, version bumping, publishing. The author is awesome too. Also making python3 tooling possible on python 2/3 packages. I'd highly recommend trying it out.

Pipenv on the other hand was not only slower, but _failed_ to actually resolve our dependencies correctly. Additionally, it was slower. And looking up the issues, I can echo that the development team seems a bit defensive and dismissive.

Re: Pipenv: promises a lot, delivers very little

#130

Post by mychael »

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…

Power tends to corrupt.
Post reply on HN