PEP 621 support and roadmap

[deronnax]

Hello.
First, thanks for all the great work.
Is PEP 621 support planned? Also, will there be a roadmap, to know what's coming next?
At our company we are very curious (and also a bit worried) about what direction Pipenv will take, what will it become. Is it in life support or is it back on track to become a key player and compete with, say, Poetry?
Thank you.

[matteius]

@deronnax -- There is a PR open from @kalebmckale that moves everything to the pyproject.toml -- could you help review if that meets the PEP 621 spec? #5836

Also, will there be a roadmap, to know what's coming next?

We are working towards better defining our goals so they are well known. At a high level, we are looking for more contributors to the project and have been working towards reducing the complexity of the code base and making it more clear. A major refactor was released and there were more edge cases than I would have liked; at this point most of that is calming down but there is still some things to sort out around local file installs (editable or not) -- there are issues tracking these things in the backlog. Most of the backlog is well tagged at this point and the tag for Contributor Candidate indicates someone may be able to help out with that issue.

This was the last attempt to formalize goals, but most of these have been completed: https://github.com/pypa/pipenv/milestone/10
Now the goals are to finish patching any regressions from the major refactor.
There is also a desire to make some improvements to pythonfinder, and convert it to vanilla dataclasses which will allow us to drop pydantic vendoring.

Longer term I am hopeful we can reach better strategies for cross platform locking.

That is kind of a short-term, mid-term and longer term outlook. As far is if its in life support, I hope that its quite clear since myself and @oz123 took over maintaining this project that we have been putting a lot of effort into getting it back on track. There have been some hickups along the way, but when I look back on some of the hurdles we have already gotten past, I feel that pipenv will continue to be a primary option when considering python package manager.

[deronnax]

Very clear and thorough, thank you so much.

[oz123]

I'd like to see pipenv drop pipfile and adopt pyproject.toml.
As for the question if it's planned, the answer is yes. I've been dreaming of it. But due to obligations to payed work and family this is put on the backlog.
I would support of merging a PR for that. It's probably going to be medium to a large size and will take alot of discussion before being merged...

[kalebmckale]

pipenv itself is moving its own configuration and metadata into a pyproject.toml as @matteius mentioned.

pipenv as a project I believe hopes to itself be compliant in the future where the Pipfile is unnecessary but an available option (like a number of other tools) as @oz123 mentioned, but there are a number of issues that need to be fixed and/or resolved to get it to a place where things are made better, not worse, by rushing into a new feature. There's also a lot of transition in the overall package-dependency space with pip itself and Python standards that increases the complexity with a package so tightly coupled to pip.