Regression from v2023.6.18 for editable package dependencies

[justin-yan]

Issue description

When installing a package in editable mode, pipenv does not include its transitive dependencies on version 2023.06.26, when it does on version 2023.06.18.

I've created an example repo here: https://github.com/justin-yan/pipenvtest/tree/1aeb6b6d28662319a0250cdd8d8a7220812ed358 where the pipenvtest package is defined with one dependency (pyyaml): https://github.com/justin-yan/pipenvtest/blob/1aeb6b6d28662319a0250cdd8d8a7220812ed358/pyproject.toml#L10

Expected result

• I'm using pipenv installed via pipx install pipenv==2023.06.18 --force
• Running pipenv lock from a clean clone of this repo.

Results in a Pipfile.lock that includes the pyyaml package:

...
    "default": {
        "pipenvtest": {
            "editable": true,
            "path": "."
        },
        "pyyaml": {
            "hashes": [
                "sha256:01b45c0191e6d66c470b6cf1b9531a771a83c1c4208272ead47a3ae4f2f603bf",
                "sha256:0283c35a6a9fbf047493e3a0ce8d79ef5030852c51e9d911a27badfde0605293",
...

Actual result

• I'm using pipenv installed via pipx install pipenv==2023.06.26 --force
• Running pipenv lock from a clean clone of this repo.

Results in a Pipfile.lock that does not include the transitive dependencies of pipenvtest:

...
        ]
    },
    "default": {
        "pipenvtest": {
            "editable": true,
            "path": "."
        }
    },
    "develop": {
        "attrs": {
            "hashes": [
...

[matteius]

Interesting, I suspect this may only be an issue for when the transitive dependencies are defined in the pyproject.toml? This will require further investigation towards a fix, thanks for your report!

[matteius]

Initial analysis revealed that get_pyproject in requirementslib.model.utils reads that pyproject.toml but is only focused on extending out the build requirements and not the actual dependencies. It should be extended to return both sets of information and the places that utilize it. In the models.requirements dependencies property, it can then extend the setup_deps list with the dependencies -- should be the path towards resolving this one.

[matteius]

@justin-yan I just had a good test run for the proposed fix of this issue if you would like to try out that branch. I just pushed a unit test as well that failed on main and passed on this branch.

[justin-yan]

Just tried it out on 2023.7.2.dev0 and can confirm that the issue seems to be resolved!