pipenv 2024.2.0 doesn't interpret my src-folder as a folder but as a package (src 0.0.7)

[fpi1337]

Hello,

I just wanted to report an issue:

Issue description

The title says it all. I have a project folder which contains a Pipfile and a src folder. The content of the src folder should be installed using pipenv install. However, instead of installing my local folder as package "src" it will end up trying to download src-0.0.7 and build a wheel out of it. This should not happen, since I explicitly state that by using the file-keyword. Check the section of my Pipfile below

[packages]
mypackage = {file = "src", editable = true}

In the past, pipenv would install this folder as a package. But now it downloads a package with a corresponding name.

There's a workaround: Inserting a "./" :

[packages]
mypackage = {file = "./src", editable = true}

Expected result

A succesful install of "MyPackage" like in previous versions (2024.0.1 and below) of pipenv.

Actual result

_self.distribution.has_ext_modules() : AttributeError: 'NoneType' object has no attribute 'has_puremodules' :
:
: note: This error originates from a subprocess, and is likely not a problem with pip. : ERROR: Failed building wheel for src : ERROR: Could not build wheels for src, which is required to install pyproject.toml-based projects ERROR: Couldn't install package: {}

Steps to replicate

In this case, you can just follow my description from above to reproduce it. But basically: just create a folder named src, put your package files in it and specify it in the Pipfile accordingly.

Best regards!

[Darsstar]

Both 2024.2.0 and 2024.0.3 behave different than previous versions have.

Instead of file we are using path however... so it might be a seperate, but related issues, or totally unrelated.

mypackage gets added to the Pipfile.lock as if it was found on an index.

Expected:

        "mypackage": {
            "editable": true,
            "path": "."
        },

Actual:

        "mypackage": {
            "version": "==1.1.4.post2+git.e6b273aa.dirty"
        },

[matteius]

Please try this branch and help me determine if it resolves your issue: https://github.com/pypa/pipenv/pull/6282

[Darsstar]

With that branch I get the expected output again 😊

[matteius]

2024.3.0 has been released. @fpi1337 could you confirm if your issue persists?

[fpi1337]

@matteius First of all, thank you for your efforts! :-) But I have a dumb question: since I've installed pipenv 2024.2.0 by using pipx under Debian 12, I am not really sure, how to update it using your released 2024.3.0.

And I don't know if this is of any interest, but I digged in deeper regarding my issue (it's probably fixed by now with this current update) but here are some notable findings (it involves poetry, so I don't know to which degree this counts):

[tool.poetry.dependencies] mypackage = { path = "src", develop = true } python = "^3.8"

poetry export -f requirements.txt > requirements.txt creates a requirements.txt with all the dependencies out of my pyproject.toml. But here's the thing:

• if my colleague uses poetry export with his Mac, he gets a requirements.txt with this entry:

mypackage @ file:///Users/xxxx/ourporject/mypackage/src ; python_version >= "3.8" and python_version < "4.0"

If we now use his created requirements.txt containining the entry above to create Pipfile and Pipfile.lock (rm -rf before of course), the reported issue will occur because the Pipfile will contain the entry like this (keep in mind that he set the develop-flag in pyproject.toml to true):

[packages] mypackage = {file = "src"}

This entry of course will prevent pipenv to function properly. It will even ignore inserting the packages in Pipfile.lock which are listed after mypackage @ file:///Users/xxxx/ourporject/src ; python_version >= "3.8" and python_version < "4.0". But then if I generate (under Debian 12) the requirements.txt, Pipfile and Pipfile.lock using poetry export I'll get a requirements.txt which looks like this:

-e file:///home/fpi/mypackage/src ; python_version >= "3.8" and python_version < "4.0"

This on the other hand creates (pipenv install) a Pipfile which looks like this:

[packages] mypackage = {file = "src", editable = true}

which pipenv install can understand properly. The "editable = true" option does the trick. Even if I set it manually in the the Pipfile, not creating everything from scratch. The -e in the requirements.txt even creates the Pipfile properly on my colleagues Mac (even keeping in mind his "develop=true" option in pyproject.toml) but not the other way around when using his created requirements.txt with mypackage @ file .....

So in general: it seems that the Mac creating workflow of every component (requirements.txt [although created by peotry export], Pipfile and Pipfile.lock) leads to this problem. So everyone else who uses his created Pipfile encounters this issue.

I hope that my description is understandable. If not, come at me again. :)

[Darsstar]

pipx upgrade pipenv

[fpi1337]

Thank you! It seems that the issue is fixed on my end. It now runs pipenv install flawlessly, even if it does not contain the editable = true option.