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

Re: Pipenv: promises a lot, delivers very little

#111

Post by rtpg » Thu, Dec 06, 2018, 2:09 AM UTC

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…

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` existing already. We could have built a tool to manipulate `requirements.txt` files instead of introducing another format and a toolchain that is _much_ slower and brittler. Though ultimately at this point Python packaging woes feel like they are at a much lower level (the fact that libraries end up being "installed" mean that preparing all your dependencies to go out to multiple servers is a mess).

Re: Pipenv: promises a lot, delivers very little

#112

Post by pvg » Thu, Dec 06, 2018, 2:11 AM UTC

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…

Pipenv keeps flouting itself

That would be weird. Perhaps you mean 'flaunting'?

Re: Pipenv: promises a lot, delivers very little

#113

Post by Dylan16807 » Thu, Dec 06, 2018, 2:15 AM UTC

chatmasta wrote: post #78

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…

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

Yes it does. Everything is installed in the venv folder. To start fresh you just delete it [and restart bash].

Re: Pipenv: promises a lot, delivers very little

#114

Post by guitarbill » Thu, Dec 06, 2018, 2:17 AM UTC

Twirrim wrote: post #75

tutuca wrote: post #66

Earlier quoted context omitted.

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.

updating requirements.txt is a pain, and also development dependencies vs normal ones usually results in two requirements files. lock files are a good way to do this, so borrowing from npm et al isn't a bad move.

(for what it's worth, i use pipenv and rather like it.)

Re: Pipenv: promises a lot, delivers very little

#115

Post by malcolmgreaves » Thu, Dec 06, 2018, 2:19 AM UTC

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!

Re: Pipenv: promises a lot, delivers very little

#116

Post by JNRowe » Thu, Dec 06, 2018, 2:30 AM UTC

cx1000 wrote: post #59

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…

PEP 582 is in the works to make __pypackages__ the Python equivalent of node_modules. Not sure if it will get accepted but I hope it does. > a mechanism to automatically recognize a __pypackages__ directory and prefer importing packages installed in this location over user or global site-packages. This will avoid the steps to create, activate or deactivate "virtual environments". https://www.python.org/dev/peps/pep-0…

That’s a great idea. I’ve just been playing with the implementation from the PEP, and it makes things really easy.

The speed of simply extracting a bunch of wheels directly in to `__pypackages__/$PYVER/lib/` is a huge benefit. It behaves well if you symlink from a global tree of extracted packages too, like an even simpler version of pundler¹.

If others want to play with it without too much breakage, I massaged the patch on to 3.7². The 3.8 base was a little too big a change for my liking ;)

1. https://github.com/Deepwalker/pundler 2. https://gist.github.com/JNRowe/502f8772861cdd21bff5144c416e4...

Edit: It’s a third of a second to stand up a complete environment with 63 wheels in its dependency tree for the project I'm playing with right now.

Re: Pipenv: promises a lot, delivers very little

#117

Post by O5vYtytb » Thu, Dec 06, 2018, 2:35 AM UTC

epage wrote: post #38

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.

sdispater has an open issue for controlling the python version - https://github.com/sdispater/poetry/issues/621 - should make it into 1.0?

Re: Pipenv: promises a lot, delivers very little

#118

Post by luord » Thu, Dec 06, 2018, 2:42 AM UTC

Meanwhile, I've recently started using the setup.py file and its install_requires and extra_required fields for production requirements and dev requirements, respectively. I don't even use requirements.txt as thanks to setup.py I only have to install the folder itself.

Am I weird? Am I not supposed to do that? Is it bad practice?

Re: Pipenv: promises a lot, delivers very little

#119

Post by RayDonnelly » Thu, Dec 06, 2018, 2:48 AM UTC

epage wrote: post #38

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.

I agree that providing toolchains is very important.

The only non-system package manager that provides Python and its own toolchains - for Linux and macOS presently - which are used to compile every C, C++ and Fortran package, including Python itself is conda and the Anaconda Distribution.

Not doing this leads to static linking and that's inefficient and insecure.

Disclaimer: I work for Anaconda Inc.

Re: Pipenv: promises a lot, delivers very little

#120

Post by JNRowe » Thu, Dec 06, 2018, 2:48 AM UTC

pseudalopex wrote: post #73

heavenlyblue wrote: post #36

Earlier quoted context omitted.

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.

Unless you change state yourself in the mean time.

`deactivate` changes `$PATH` back to what it was when you ran `activate` for example, which isn’t likely to be what you want if you’ve changed it since. At least with a subshell you can know what state you’re returning to with .

That is part of the problem with the `virtualenv` story in my eyes. It offers the illusion of isolation, but falls down in quite a few ways which are annoying when they do pop up.