fix inconsistent behavior: poetry install wheel with "malformed" filename fails from remote url, but works locally

[x] I have searched the issues of this repo and believe that this is not a duplicate.
[x] I have searched the FAQ and general documentation and believe that my question is not already covered.

Feature Request

I need to install a third-party wheel from a http url which has a "malformed" package filename. Critically, among other missing things, it does not contain a numerical package version number. Let's assume the filename is the following, where I've anonymized the actual package name except for the part in bold: packagename-any-py3-none-any.whl

In the pyproject.toml I added this line:

packagename = {url = "https://somewebsite.com/some/path/packagename-any-py3-none-any.whl"}

The installation fails because, despite the wheel is downloaded properly in the local poetry cache directory, before actual installation there is a filename validity check here that returns None and prevents the wheel from being installed. At the time of writing, the filename validation regex is as follows:

wheel_file_re = re.compile(
    r"^(?P<namever>(?P<name>.+?)-(?P<ver>\d.*?))"
    r"(-(?P<build>\d.*?))?"
    r"-(?P<pyver>.+?)"
    r"-(?P<abi>.+?)"
    r"-(?P<plat>.+?)"
    r"\.whl|\.dist-info$",
    re.VERBOSE,
)

Notice there is a mandatory version capture group (?P<ver>\d.*?) that requires a number to appear in the package name.

On the other hand, the installation works perfectly fine if I install the wheel from a manually downloaded file which is put in the same directory as the pyproject.toml. The following configuration works as expected, because the filename validity check, for some reason, is not performed when installing from a local file:

packagename = {file = "./packagename-any-py3-none-any.whl"}

My feature request is to allow the installation to succeed not only for the local installation, but also for the remote url case. I'm not sure how this would be impacting the necessity for the filename validation.

On a minor side note, the "invalid filename" exception that is internally raised during installation is completely silent, so I had to spend quite some time debugging poetry code to understand what was the reason. I think that, if the filename check has to stay in place, it would be helpful to let the user know the particular reason why the installation failed, i.e., the filename was malformed because missing the numeric version.

python-poetry / poetry

fix inconsistent behavior: poetry install wheel with "malformed" filename fails from remote url, but works locally #8889

Feature Request