On 06-06-2023 09:39, Elliott Sales de Andrade wrote:

On Mon, Jun 5, 2023 at 6:45 AM Sandro lists@penguinpee.nl wrote:

...

Hi again,

I'm trying to understand why I'm getting a circular import error running tests only in F37 [1].

It's an easy fix adding an empty __init__.py in %prep, but why are F38 and rawhide buildroots happy not having that file, while F37 complaints?

Looking at the F37 log, you can see that only a few files were copied:

creating build/lib/palettable copying palettable/utils.py -> build/lib/palettable copying palettable/palette.py -> build/lib/palettable copying palettable/__init__.py -> build/lib/palettable

with no trace of something named cmocean. And then looking at F38, you see:

/usr/lib/python3.11/site-packages/setuptools/command/build_py.py:202: SetuptoolsDeprecationWarning: Installing 'palettable.cmocean' as data is deprecated, please list it in `packages`.

   ############################
   # Package would be ignored #
   ############################
   Python recognizes 'palettable.cmocean' as an importable package,
   but it is not listed in the `packages` configuration of setuptools.

   'palettable.cmocean' has been automatically added to the distribution only
   because it may contain data files, but this behavior is likely to change
   in future versions of setuptools (and therefore is considered deprecated).

   Please make sure that 'palettable.cmocean' is included as a

package by using the `packages` configuration field or the proper discovery methods (for example by using `find_namespace_packages(...)`/`find_namespace:` instead of `find_packages(...)`/`find:`).

   You can read more about "package discovery" and "data files" on setuptools
   documentation page.

So you can see that the newer versions are happily working, but only through some bit of compatibility concerns. It may eventually break there as well.

I'm not quite sure I follow your explanation/analysis.

Yes, there is a deprecation warning, which should be addresses by upstream. I'll let them know, possibly providing a patch.

I can also see that the build for F37 is incomplete. Indeed not all modules have been added to the wheel.

What I fail to understand is how adding test/__init__.py fixes the problem. I mean test is not even consulted during build. It resides outside the palettable namespace.

diff --git a/python-palettable.spec b/python-palettable.spec index 3334dc8..8d124db 100644 --- a/python-palettable.spec +++ b/python-palettable.spec @@ -32,6 +32,7 @@ BuildRequires: git-core

%prep %autosetup -p1 -n %{pypi_name}-%{version} -S git +touch test/__init__.py

%generate_buildrequires %pyproject_buildrequires

This is the only change I made to the spec file. And all of a sudden it works [2]? I didn't make any changes to pyproject.toml as suggested in the deprecation warning.

Sorry, if I wasn't clear enough in my initial post.

...

The versions of the involved packages only differ in minor / patch versions between F37 and F38, if at all. With python-setuptools-wheel being the only package with a different major version.

python3-devel 3.11.3-2.fc37 3.11.3-2.fc38 python3-pytest 7.1.3-2.fc37 7.2.2-1.fc38 pyproject-rpm-macros 1.8.0-1.fc37 1.8.0-1.fc38 python-rpm-macros 3.11-5.fc37 3.11-10.fc38 python-pip-wheel 22.2.2-3.fc37 22.3.1-2.fc38 python-setuptools-wheel 62.6.0-3.fc37 65.5.1-2.fc38

[1] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6002232/

[2] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6010125/

-- Sandro

On 07-06-2023 22:15, Sandro wrote:

On 07-06-2023 02:30, Sandro wrote:

...

On 06-06-2023 09:39, Elliott Sales de Andrade wrote:

...

On Mon, Jun 5, 2023 at 6:45 AM Sandro lists@penguinpee.nl wrote:

...

Hi again,

I'm trying to understand why I'm getting a circular import error running tests only in F37 [1].

It's an easy fix adding an empty __init__.py in %prep, but why are F38 and rawhide buildroots happy not having that file, while F37 complaints?

Looking at the F37 log, you can see that only a few files were copied:

creating build/lib/palettable    copying palettable/utils.py -> build/lib/palettable    copying palettable/palette.py -> build/lib/palettable    copying palettable/__init__.py -> build/lib/palettable

with no trace of something named cmocean. And then looking at F38, you see:

/usr/lib/python3.11/site-packages/setuptools/command/build_py.py:202: SetuptoolsDeprecationWarning:     Installing 'palettable.cmocean' as data is deprecated, please list it in `packages`.

############################        # Package would be ignored #        ############################        Python recognizes 'palettable.cmocean' as an importable package,        but it is not listed in the `packages` configuration of setuptools.

'palettable.cmocean' has been automatically added to the distribution only        because it may contain data files, but this behavior is likely to change        in future versions of setuptools (and therefore is considered deprecated).

Please make sure that 'palettable.cmocean' is included as a package by using        the `packages` configuration field or the proper discovery methods        (for example by using `find_namespace_packages(...)`/`find_namespace:`        instead of `find_packages(...)`/`find:`).

You can read more about "package discovery" and "data files" on setuptools        documentation page.

So you can see that the newer versions are happily working, but only through some bit of compatibility concerns. It may eventually break there as well.

I'm not quite sure I follow your explanation/analysis.

Yes, there is a deprecation warning, which should be addresses by upstream. I'll let them know, possibly providing a patch.

I can also see that the build for F37 is incomplete. Indeed not all modules have been added to the wheel.

What I fail to understand is how adding test/__init__.py fixes the problem. I mean test is not even consulted during build. It resides outside the palettable namespace.

diff --git a/python-palettable.spec b/python-palettable.spec index 3334dc8..8d124db 100644 --- a/python-palettable.spec +++ b/python-palettable.spec @@ -32,6 +32,7 @@ BuildRequires:  git-core

%prep   %autosetup -p1 -n %{pypi_name}-%{version} -S git +touch test/__init__.py

%generate_buildrequires   %pyproject_buildrequires

This is the only change I made to the spec file. And all of a sudden it works [2]? I didn't make any changes to pyproject.toml as suggested in the deprecation warning.

A good night's sleep, a clear head and a rubber duck the size of en elephant have finally opened my eyes.

Adding test/__init__.py only fixed the tests, not the package. The resulting RPM is stripped of all submodules.

I changed the pyproject.toml file dropping the tool.setuptools.packages.find table and adding:

[tool.setuptools] packages = ["palettable"]

Now all submodules are included and tests succeed without needing to add __init__.py. Locally, using `fedpkg --release f37 mockbuild -N`, that is. Building from the resulting SRPM in Copr [3] or Koji [4] the submodules are still missing.

I'm at a loss, once again, as to what exactly is going on here.

While I still don't understand the difference in behavior between F37 and F38/rawhide wrt to setuptools, it turned out I was one character short in my original solution. I added:

include = ["palettable"]

to the tool.setuptools.packages.find table. That should have been:

include = ["palettable*"]

That `packages = ["palettable"]` excludes submodules by default, I find disturbing.

Long story short: I learned something! But setuptools and I won't be getting married anytime soon...

[3] https://copr.fedorainfracloud.org/coprs/gui1ty/neuro-sig/build/6017925/ [4] https://koji.fedoraproject.org/koji/taskinfo?taskID=101915616

-- Sandro