PEP 503 compliance in poetry-core 1.1.0 causes my package to no longer be installed properly

[vancromy]

Version 1.1.0 of poetry-core implemented PEP 503 compliance (#394) but this seems to be breaking local installations of my package (for other developers using my package who do no use poetry). In other words, when running pip install . pre-1.1.0 is not the same as post 1.1.0.

Here's my project.toml file

Here's a pip install log from before the 1.1.0 release:

And here's a pip install log from after the release:

And the errors I'm getting after installing with version 1.1.0:

Locking poetry-core version to pre-1.1.0 (as follows) solves my issue for now.:

[build-system]
requires = ["poetry-core>=1.0.8,<1.1.0"]

I thought I would raise this in case backwards compatibility for packages that haven't caught up with PEP503 normalised names was still expected.

I agree that I should work on changing my package structure to fit normalized PEP503 names but doing so would mean I would lose all the history of my package on pypi so its not a decision I can make lightly and will need to be discussed internally first. So if the only valid fix is locking poetry-core version, then I guess I will stick to that :)

[vancromy]

Upon closer review of the tracebacks, it seems to be an issue with me using the __name__ dunder combined with importlib.metadata. I'm using importlib.metadata to inspect my package's metadata to then set the __version__ dunder for my package (a long-winded way to extract the version from the toml file...)

[dimbleby]

Please provide a reproduction. A little github project or a docker container would do the job.

[dimbleby]

Oh I see that your pyproject.toml is in a full git repository... So I cloned that and everything went fine:

$ pip install .
... pip output ...

$ python
Python 3.10.4 (main, Jun 29 2022, 12:14:53) [GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import akerbp.mlpet
>>> akerbp.mlpet.__version__
'3.1.1a1'

[neersighted]

Moved from poetry-core as somehow issues got turned on there by mistake -- we use one tracker for both Poetry and poetry-core.

[dimbleby]

Oh, I remember now. This is going to be a duplicate of #6198, in which the discussion concluded that importlib at python 3.10 handled this fine (per my attempt to reproduce), and that poetry wasn't wrong.

[neersighted]

Good catch, I also remember that issue now. We're probably going to need some sort of FAQ entry for this.

[elemakil]

Hi @neersighted @dimbleby,

sorry for hijacking this issue but I think I have the same issue and I don't understand the solution presented here or in #6198. We are using implicit namespace packages as per to place all our python packages within an organisation specific namespace and avoid naming collisions.

As an example consider the following pyproject.toml

[tool.poetry]
name = "org.module"
version = "0.1.0"
description = ""
authors = ["Your Name <you@example.com>"]
readme = "README.md"
packages = [
    { include = "org", from = "src" },
]

[tool.poetry.dependencies]
python = "^3.7"

[build-system]
requires = ["poetry-core>=1.1.0"]
build-backend = "poetry.core.masonry.api"

which is accomodated by an empty Readme.md and a single source file located in src/org/module/__init__.py which contains

import sys

if sys.version_info >= (3, 8):  # pragma: no cover
    import importlib.metadata as importlib_metadata
else:  # pragma: no cover
    import importlib_metadata

def get_version():
    return importlib_metadata.version(__name__)

Reproduction steps

1. Install poetry 1.1.15
2. Run poetry install
3. Run poetry run python -c 'from org.module import get_version; print(get_version())'

This produces the (expected) output

0.1.0

1. Install poetry 1.2.0
2. Run poetry install
3. Run poetry run python -c 'from org.module import get_version; print(get_version())'

This produces a crash

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/<SNIP>/Temp/poetry-1.2-issue/src/org/module/__init__.py", line 9, in get_version
    return importlib_metadata.version(__name__)
  File "/home/<SNIP>/.pyenv/versions/3.9.1/lib/python3.9/importlib/metadata.py", line 551, in version
    return distribution(distribution_name).version
  File "/home/<SNIP>/.pyenv/versions/3.9.1/lib/python3.9/importlib/metadata.py", line 524, in distribution
    return Distribution.from_name(distribution_name)
  File "/home/<SNIP>/.pyenv/versions/3.9.1/lib/python3.9/importlib/metadata.py", line 187, in from_name
    raise PackageNotFoundError(name)
importlib.metadata.PackageNotFoundError: org.module

• I have tried replacing name = "org.module" by name = "org-module" in the [tool.poetry] section of pyproject.toml as suggested in Regression in namespace package metadata on poetry-core 1.1.0rc1 #6198, however, this does not resolve the issue.
• I can confirm that this issue only occurs when using python 3.8.6 or 3.9.1 and vanishes when I use 3.10.5.
• I've executed poetry build with both poetry 1.1.15 and 1.2.0 and compared the contents of the generated .tar.gz and could not find any difference.

Can you provide instructions how to solve this problem?

[dimbleby]

#6198 reported that name = "org-module" did resolve this.

Indeed it seems unlikely that a fresh install of code that doesn't mention the text org.module would fall over complaining about org.module. Perhaps you still had something from a previous try interfering when you did this?

Alternatively (warning, untested) perhaps spelling out org-module in place of __name__ while you are stuck at an older importlib would work.

[elemakil]

Thanks for the quick reply. I don't think interference from a previous attempt is an issue but of course you never know.

It appears the issue was truly with importlib and I didn't fully think the implications through. Hard-coding org-module in place of __name__ does indeed resolve this. As does using the "backported" importlib-metadata installed from pypi instead of the builtin version. We've been using this for python < 3.8, I guess we'll have to add it to version 3.8 and 3.9 as well.

Thanks to @dimbleby for pointing me in the right direction!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.