Requesting community testing of branch that migrates away from Requirementslib models

[matteius]

Hey Pipenv Community 👋

We are on the verge of releasing a major refactor to the way pipenv works and its pretty exciting. However, based on the the breadth of the changes, it would be important to get members of the community to volunteer to help test this PR before we release it: #5793

This branch not only heavily moves away from the requirementslib models and introduces new utility methods for accomplishing the same thing. I believe heading in this direction will make pipenv easier to maintain and more resilient in the long run.

To help, please consider installing the above branch:
pip uninstall pipenv --yes
pip install -e git+https://github.com/pypa/pipenv.git@draft-no-reqlib#egg=pipenv

Backstory:
The requirementslib models are a nested mess. For example, locally I fixed the issue of wheel extras not being installed and broke a bunch of other stuff in the process. There is no isolation between what the models do as they self reference each-other. There are a million ways to break edge cases of requirementslib trying to improve it, and so I've found it is not worth trying to salvage it -- the essential contract was about converting between Pipfile entries to pip lines and InstallReq objects, along with some metadata and arriving at lock file entries and being able to generate install lines and requirements from those as well.

I have re-established what interfaces are actually needed to get between Pipfile, Pipfile.lock and pip lines. In order to get there, I had to drop --skip-lock first to simplify the playing field. We could consider a different command interface for going from Pipfile entries to pip install lines, but I am not sure its worth it as the benefits of pipenv are in the lock file constraints.

Here is what the high level architecture looks like:

[matteius]

The plan is to most likely merge this tomorrow evening and cut a new release 🚀

[matteius]

pipenv 2023.8.19 has been released!