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

Re: Pipenv: promises a lot, delivers very little

#51

Post by devnonymous » Wed, Dec 05, 2018, 10:45 PM UTC

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…

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

I don't think that the parent disagreed with that. The point, as I understood it, was that this beta stage improvement was marketed as being ready. IOW, if pipenv was not Kenneth's project, it likely would have evolved in, to use your phrase, a straighter line.

Re: Pipenv: promises a lot, delivers very little

#52

Post by black-tea » Wed, Dec 05, 2018, 10:47 PM UTC

lvh wrote: post #14

The article doesn't mention pyenv, which I've used to great effect. It does pretty much everything I want, including having multiple environments active at once (so that tools that want to do their own virtualenv management, like tox, can find a python2.7, python3.5, python3.6, python3.7, pypy2... in PATH) and automatically activating a virtual environment when I go into a particular directory. For a project to be ea…

I use pyenv on some distros and it is good, but on Gentoo there is no point because Python is slotted which means you can install multiple versions and have them all available on PATH. I then use virtualenvwrapper and specify the version manually (e.g. -p python3.7). Alternatively you can always do python3.7 -m venv ...).

The annoying thing with pip freeze is it doesn't have a concept of a "world" file like emerge (Gentoo). With emerge when you install a package it gets entered into your world file but the dependencies do not. That way you always know what you actually want, rather than just incidental dependencies. I wish pip freeze did that.

Re: Pipenv: promises a lot, delivers very little

#53

Post by avip » Wed, Dec 05, 2018, 10:49 PM UTC

holografix wrote: post #49

avip wrote: post #27

I've long freed myself from the exhausting pipenv/virtualenv/pienv/conda rat-race by using docker. The only downside is some annoying IDEs refuse to acknowledge the existence of interpreter in a container.

can you get VSC code completion to use a python interpreter in a Docker container?

I can't! In fact that was my main motivation in posting that, maybe a wiser HNer will enlighten me.

Re: Pipenv: promises a lot, delivers very little

#54

Post by umvi » Wed, Dec 05, 2018, 10:53 PM UTC

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, but then there is no python_modules folder to be found. Instead it downloads it to some obscure directory halfway across my computer. If I want to start fresh I guess I have to trust the tool's uninstall function? And it's unclear if I need sudo or not. Also I can no longer just run my program, I have to run it with pipenv now? Python requires too much cognitive burden for module/dependency/virtualenv management.

For me it's to the point that developing using a docker image with globally installed python modules is easier to manage and wrap my brain around than using pipenv/virtualenv/whatever.

Re: Pipenv: promises a lot, delivers very little

#55

Post by [deleted] » Wed, Dec 05, 2018, 10:53 PM 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.

[deleted]

Re: Pipenv: promises a lot, delivers very little

#56

Post by dnlsrl » Wed, Dec 05, 2018, 10:56 PM UTC

This article has been really informative and has given me context on what the hell is the problem with pipenv in people's opinion, which I have been wondering about for a while, I'll check out Poetry soon. Reading all the context, however, has reminded me that people are mainly assholes and now I feel I need to stop using social media completely, and the Internet for that matter.

Re: Pipenv: promises a lot, delivers very little

#57

Post by moonsun » Wed, Dec 05, 2018, 10:57 PM UTC

I don't write libraries but pipenv works well for a simple flask application because I don't ask much of it.

All I want is a simpler file to look at compared to requirements.txt

Here is my guide for newbies like me

1. Use Pipenv in development.

2. Create a requirements.txt each time you make any changes to your pipenv. Commit all three files: pipenv, pipenv lock, and requirements.txt to git.

3. Use this requirements.txt in production.

4. ???

5. Profit

Now here is my only gripe:

I believe pipenv is meant for simple people like me. I have to say I want to use Python 3. There is no way to say I accept anything 3.5+

My understanding is that pipenv is not meant for people who actually know python inside out. My use case is that it lets me keep track of what dependencies I installed as opposed to what dependencies my dependencies installed. This should have been the ONLY problem that pipenv fixes but like the old saying goes... no project is complete until it is able to send mail (sorry I probably said it wrong).

Re: Pipenv: promises a lot, delivers very little

#58

Post by lvh » Wed, Dec 05, 2018, 10:59 PM UTC

black-tea wrote: post #52

lvh wrote: post #14

The article doesn't mention pyenv, which I've used to great effect. It does pretty much everything I want, including having multiple environments active at once (so that tools that want to do their own virtualenv management, like tox, can find a python2.7, python3.5, python3.6, python3.7, pypy2... in PATH) and automatically activating a virtual environment when I go into a particular directory. For a project to be ea…

I use pyenv on some distros and it is good, but on Gentoo there is no point because Python is slotted which means you can install multiple versions and have them all available on PATH. I then use virtualenvwrapper and specify the version manually (e.g. -p python3.7). Alternatively you can always do python3.7 -m venv ...). The annoying thing with pip freeze is it doesn't have a concept of a "world" file like emerge (G…

I prefer to keep locally installed Pythons for regular use everywhere, though I guess some distros get the same effect by patching pip to make `--user` the default (and hence pip install xyzzy goes to my home directory instead of messing with something that belongs to the OS).

In particular, one way this has bitten me is if the OS expects a certain Python with a certain set of dependencies to be available for systems its responsible for. Isn't portage itself written in Python for example?

Re: Pipenv: promises a lot, delivers very little

#59

Post by cx1000 » Wed, Dec 05, 2018, 10:59 PM UTC

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-0582/

Re: Pipenv: promises a lot, delivers very little

#60

Post by cyberpanther » Wed, Dec 05, 2018, 11:01 PM UTC

pipenv is not perfect but it is definitely headed in the right direction. It is a lot easier for beginners to get started with which is one of the best things I've found.

To address one of the problems, Running Scripts: basic complaint is you are starting a new shell always and you have to prefix all commands.

Prefixing commands sucks but you can get around it pretty easy with an alias.

alias pr="pipenv run" alias dm="pipenv run python manage.py"

now 'pipenv run python manage.py startapp foobanizer'

becomes 'dm startapp foobanizer'

or 'pr django-admin startapp foobanizer'

As for the shells. I really like this feature because it's a lot cleaner. With activate and deactivate you are essentially mutating the current shell which can be dangerous. Also because it loads your ENVs on every run, it's easier to switch out ENVs.