Live data from Hacker News

Pipenv: promises a lot, delivers very little

chriswarrick.com

61–70 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#61
post #59
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 would be great! Any way to upvote or otherwise give the equivalent of a GitHub thumbs up to show support for it?

Re: Pipenv: promises a lot, delivers very little

#62
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 resolution of dependencies and compatibility ranges (hard to solve in general).

Re: Pipenv: promises a lot, delivers very little

#63

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 deny that, what I am (and the article is) saying is that we were sold on Pipenv being "the officially recommended Python packaging tool from Python.org".

And PyPA didn't refute it, and Heroku didn't refute it, so the community bought it.

Yes, introducing a Lockfile is huge, and it was massively needed, and thats why when we were told "heres the official way to do it", we got excited. Then we got daily breaking updates, rude issue close messages, and a giant backtrack of "its free and still under development, why do you expect so much from us?"

Re: Pipenv: promises a lot, delivers very little

#64
I tried pipenv, then poetry, then pip-tools [1]. pip-tools worked best for me. I control my own virtualenvs, and can compose the requirements files pip-tools compiles. It's vendored in pipenv, so it's basically the dependency engine for pipenv.

[1] https://github.com/jazzband/pip-tools

Re: Pipenv: promises a lot, delivers very little

#66

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.

Re: Pipenv: promises a lot, delivers very little

#68

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 YEARS with regular setuptools, is incredibly simple to use and completly compatible with the standard "setup.py stuff" workflow (and hence the whole legacy tool stack) ?

Yep. And nobody talks about it.

Let me (re)introduce...

Setup.cfg !

Oh, I know... Most people believes it's a useless file.

After all, the Python documentation seldom states to use it and for only one tiny option:

https://docs.python.org/3.7/distutils/configfile.html

But no. Setup.cfg is awesome !!

Put one line in setup.py:

    import setuptools; setuptools.setup()
And you can now put all the rest - yes, everything - in setup.cfg. It's perfectly documented:

https://setuptools.readthedocs.io/en/latest/setuptools.html#...

Not only it has been working since 2016, but it has fantastic goodies:

    version = attr: src.__version__ 
will include the version from __init__.py

     "options.data_files" 
replaces the MANIFEST

     "license =  file: LICENCE.txt" 
loads the licence from any text file

Try it, it just works. And you can "python setup.py sdist upload" as usual with it. You don't need any new tool.

Now why did the PyPA decide to forget about this and create a new format ? The short explanation in PEP 518 is a bad joke. And why does nobody talks about it ?

When I asked the PyPA, they told me they were too invested in the new project to stop now. I don't like this answer at all: we suffered enough with python packaging during the "distutils, eggs, etc" fiasco.

setup.cfg works. It works now. It's nice. It's compatible. It does what we need.

Use it. Talk about it. Write about it.

Make sure a lot of people knows so that tool makers and PyPA finally acknowledge that there is not need for the XKCD comics about standard to be true again.

Re: Pipenv: promises a lot, delivers very little

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

Use conda
Post reply on HN