Pipenv: Time for new release, maybe?

[dimaqq]

It will soon be a year since last release... a gazillion commits made in the meantime... surely there's something good in those... 🙏please 🙏 pretty please 🙏new release 🙏

[yhoiseth]

Previous discussions: #3978 and #3742

[dimaqq]

I’m using pipenv in a couple of projects and poetry in another few.

A year ago, pipenv had indisputable lead, in quality, usability and vision (all seen through a prism of an end-user). 😃

Since then, I imagine that lots of work happened in both projects. I can’t see the result in pipenv and I can see the result in poetry.

@frostming you seem active here, perhaps you can get permissions to publish pre-releases?

Overall this reminds me of what they say about early days of UNIX. (Was it?) “Worse is better”, meaning a project that has fewer features and more bugs becomes more popular because many contribute, while the project that was initially pretty good stagnates, perhaps because contributing is less necessary or harder.

I wonder if the latter is the case simply because pipenv does more and thus accumulated more fragile corner cases, or simply because someone left or someone doesn’t have permission... 🧐

[nicktimko]

Fewer features/easier to release = pip-tools, which it sounds like pipenv may be using?

Update from March 14, 2019 [...] Your choice today is mostly between using pip-tools directly, using Pipenv (which is a Swiss army knife kind of tool that internally relies on pip-tools), or newer tooling like Poetry. [...]

— Better Package Managemen by Vincent Driessen

pip-tools doesn't manage the virtual environments for you (which is a feature that's usually more annoying than it's worth for me in Pipenv).

Conversion workflow:

1. Covert Pipfile back to a "requirements.txt" like format with the same pinned (django==1.11.7) / limited range (marshmallow<3) / free (*) versions. Name that requirements.in.
2. Build it into requirements.txt with something like pip-compile --quiet --generate-hashes --output-file=requirements.txt requirements.in. The file will include requirements
3. Replace pipenv in build toolchain with native pip install -r requirements.txt

If you have inline/editable packages in the repo (that you install with -e), Pipenv kinda has better support around them (requires some path editing in the pip-compile output), and there may be some other edge cases.

[tkcranny]

Master hasn't been touched for a month now, and it only looks like minor tweaks have been made for a couple months before that.

Is Pipenv dead now? 😭 If not, it's certainly doing a good impression of an abandoned project, compared to say pip itself.

The lack of development, plus no release for over a year now does not look good for what was supposed be the official, one-stop-shop for Python Package Management. I had such good impressions and high hopes for Pipenv this time last year, especially as it appeared to be backed by the PyPA and the PSF. The Python community is hurting for something similar to Node/Yarn, NuGet, or go get for example and yet Pipenv has just withered despite so much interest.

With the critical bugs, accumulating unresolved and unanswered tickets, AWOL maintainers, and no support or updates, we have no option but to start unwinding Pipenv's presence in our stacks & workflows, and return to manual venv management.

Pipenv has been a disappointment, and Pipenv has tarnished Python itself.

[oz123]

Pipenv has been a disappointment, and Pipenv has tarnished Python itself.

Indeed. The damage is incredibly unacceptable. The PyPA needs to say something. Either archive the project or pick it up.

[nicktimko]

I share some frustration with others, but I'd urge others to try to consider how much may be involved in cutting a new release. Asking for a silver-bullet version is a bit much.

[...] trying to triage plenty of upstream issues and make an automated release pipeline [...]

[...] putting such words upon open source devs who spend their spare time on such a complex project is not cordial at all while I admit there some room to improve for the release processes. Suggestions are welcomed but not sarcasm.

— frostming, 2019-05-13 https://github.com/pypa/pipenv/issues/3742#issuecomment-492045754

That said, a (very brief) update on blockers upstream, from pip or other libs, would be awesome and might help us users appreciate how much is going into the next version. in #3742, pip and friends were mentioned:

Release cadence came to a super dramatic halt because of a _lot_ of upstream issues (pip broke, setuptools broke, then pip and setuptools both released breaking fixes, and we have about 15 upstream dependencies which I personally maintain and which need to be fixed to support a pipenv release)

I am currently cutting releases of the last 2 assuming tests pass, so that we can refocus on cutting a pipenv release now.

Apologies for the delay, but the issue backlog is quite long and I am definitely not excited about triaging

— techalchemy, 2019-05-14 https://github.com/pypa/pipenv/issues/3742#issuecomment-492100711

It looks like frostming has been single-handedly trying to keep the flame alive while other contributors haven't had the time to support Pipenv, but if they get burnt out then it will be a dark day. I'm unaware of any other devs working on it, and I fear that there's a vicious cycle set up of extremely high hopes for Pipenv (admittedly set up by the early marketing), lots of users wanting every use-case fulfilled, an improved version is released (even if bugfixes only), and the devs that did it get flamed because it didn't fix it all or add all the features.

@oz123 if you're worried about the tarnishing, I'd suggest trying to advance alternatives where you can. Poetry, pip-tools, and such live on.

[petervanderdoes]

I truly believe pipenv is dead. The Python Foundation posted that is seeking developers for paid contract to improve pip
Some quotes from the article.

The Python Software Foundation Packaging Working Group is receiving funding to work on the design, implementation, and rollout of pip's next-generation dependency resolver.

So the focus is on pip not pipenv.

pip is the official package installer for Python.

So the official package installer is not pipenv.

We plan to begin the project in Quarter 1 of 2020.

It's also not clear for me why Python Packaging Authority has put full support in pipenv to be honest. Pipenv is designed for application dependency management, rather than libraries. From the pipenv docs (https://pipenv-es.readthedocs.io/es/stable/advanced.html#pipfile-vs-setup-py)

Of course, Pipfile and Pipenv are still useful for library developers, as they can be used to define a development or test environment.

In other words, pipenv was not build to support library developers.

As a user think it's time to drop pipenv, or rollback.

I think Python Packaging Authority should make the "tough" decision to retire pipenv. It seems to take to many man hours to keep the software afloat. The fact that it's so hard to update pipenv after updated upstream software says a lot about how the software is written. I mean Poetry (yet another packaging tool) has had no problems releasing new versions.

[JBKahn]

I've already switched all my work over to poetry as I grew too concerned with the state of pipenv.

I think the Python Packaging Authority should focus on the core of these issues (making a world class dependancy resolver, potentially making one that can make use of cached data on pypi for example, making a flexible spec for a lock file, etc...) rather than on the cli/interface of tools that would replace pip. Pip and the tools that power it could be used as the basis for alternatives rather than having these third party tools reinvent the wheel every time. I think pipenv is a large project to take on for the Packaging Authority and it would be a good idea to retire or cut it loose.

[nicktimko]

@petervanderdoes you could write a PR for this file https://github.com/pypa/packaging.python.org/blob/master/source/guides/tool-recommendations.rst to update it with Poetry, pip-tools and others.

[antnieszka]

@nicktimko let's start with something, any further suggestions?
https://github.com/pypa/packaging.python.org/pull/683

[pradyunsg]

Closing in favor of #4058