[BUG] Weird warning for pure-Cython submodule on Windows

[MikhailRyazanov]

setuptools version

at least 75.3.2 and 80.9.0

Python version

at least 3.8, 3.11, 3.12, 3.13

OS

Windows

Additional environment information

Noticed on GitHub CI, can’t test on plain Windows yet.

Description

A weird warning appears during pip install and python -m build --wheel for a project containing a pure-Cython submodule.

For a minimal example, consider the following project structure (see the repository):

.
├── gnvoerk
│   ├── __init__.py
│   ├── lib
│   │   ├── __init__.py
│   │   └── say.pyx
│   ├── __main__.py
│   └── _version.py
├── LICENSE.txt
├── MANIFEST.in
├── pyproject.toml
├── README.rst
└── setup.py

It has a Cython extension in a subdirectory with an empty __init__.py and one .pyx file. The .pyx file is listed in MANIFEST.in (all .py files also, but __init__.py should be discovered automatically anyway, if I understand correctly).
Building a sdist works fine, yielding the expected results on all tested platforms. However, pip install and building a wheel work as expected on Linux and on macOS, but on Windows produce a cryptic warning:

C:\hostedtoolcache\windows\Python\3.11.9\x64\Lib\site-packages\setuptools\command\build_py.py:212: _Warning: Package 'gnvoerk.lib' is absent from the `packages` configuration.
!!

        ********************************************************************************
        ############################
        # Package would be ignored #
        ############################
        Python recognizes 'gnvoerk.lib' as an importable package[^1],
        but it is absent from setuptools' `packages` configuration.

        This leads to an ambiguous overall configuration. If you want to distribute this
        package, please make sure that 'gnvoerk.lib' is explicitly added
        to the `packages` configuration field.

        Alternatively, you can also rely on setuptools' discovery methods
        (for example by using `find_namespace_packages(...)`/`find_namespace:`
        instead of `find_packages(...)`/`find:`).

        You can read more about "package discovery" on setuptools documentation page:

        - https://setuptools.pypa.io/en/latest/userguide/package_discovery.html

        If you don't want 'gnvoerk.lib' to be distributed and are
        already explicitly excluding 'gnvoerk.lib' via
        `find_namespace_packages(...)/find_namespace` or `find_packages(...)/find`,
        you can try to use `exclude_package_data`, or `include-package-data=False` in
        combination with a more fine grained `package-data` configuration.

        You can read more about "package data files" on setuptools documentation page:

        - https://setuptools.pypa.io/en/latest/userguide/datafiles.html


        [^1]: For Python, any directory (with suitable naming) can be imported,
              even if it does not contain any `.py` files.
              On the other hand, currently there is no concept of package data
              directory, all directories are treated like packages.
        ********************************************************************************

!!
  check.warn(importable)

after which the .pyx is nevertheless added (twice!):

copying gnvoerk\lib\say.pyx -> build\lib.win-amd64-cpython-311\gnvoerk\lib
copying gnvoerk\lib\say.pyx -> build\lib.win-amd64-cpython-311\gnvoerk\lib

The resulting wheel, however, looks correct:

Archive:  dist/gnvoerk-0.0.1-cp311-cp311-win_amd64.whl
  Length      Date    Time    Name
---------  ---------- -----   ----
       35  2025-10-09 07:11   gnvoerk/__init__.py
      183  2025-10-09 07:11   gnvoerk/__main__.py
       23  2025-10-09 07:11   gnvoerk/_version.py
        0  2025-10-09 07:11   gnvoerk/lib/__init__.py
    30720  2025-10-09 07:12   gnvoerk/lib/say.cp311-win_amd64.pyd
       83  2025-10-09 07:11   gnvoerk/lib/say.pyx
     1094  2025-10-09 07:12   gnvoerk-0.0.1.dist-info/licenses/LICENSE.txt
      333  2025-10-09 07:12   gnvoerk-0.0.1.dist-info/METADATA
      101  2025-10-09 07:12   gnvoerk-0.0.1.dist-info/WHEEL
        8  2025-10-09 07:12   gnvoerk-0.0.1.dist-info/top_level.txt
      865  2025-10-09 07:12   gnvoerk-0.0.1.dist-info/RECORD
---------                     -------
    33445                     11 files

and works as expected.

(If this matters, the above is done without build isolation for the reasons explained in pyproject.toml.
Also, adding

[tool.setuptools.packages.find]
include = ["gnvoerk*"]

to pyproject.toml doesn’t help, neither harms.)

So the question is whether I’m doing something wrong, or Setuptools has a bug?

• If I’m wrong:
  • How to do this properly?
  • Why the warning appears only on Windows?
  • Why the warning and the referenced documentation are so unhelpful in this situation?
• If this is a bug:
  • Please correct it.
  • Please suggest a workaround that will work in previous Setuptools versions and will not break in the future.

(Not sure whether issue #3340 is related, since it’s really not my case: I do have __init__.py, and it’s definitely not a “namespace package”.)

Expected behavior

See above.

How to Reproduce

See above.

Output

See above.

[MikhailRyazanov]

An educated guess: in this piece of code

setuptools/setuptools/command/build_py.py

Lines 197 to 212 in 9c4d383

	for path in self._filter_build_files(files, egg_info_dir):
	d, f = os.path.split(assert_relative(path))
	prev = None
	oldf = f
	while d and d != prev and d not in src_dirs:
	prev = d
	d, df = os.path.split(d)
	f = os.path.join(df, f)
	if d in src_dirs:
	if f == oldf:
	if check.is_module(f):
	continue # it's a module, not data
	else:
	importable = check.importable_subpackage(src_dirs[d], f)
	if importable:
	check.warn(importable)

paths in files and/or src_dir most probably have forward slashes. Non-Windows platforms also use forward slashes for os.path.split() and os.path.join(), so everything works consistently. But os.path on Windows uses backslashes, so perhaps these manipulations lead to some mess with forward and backslashes, and thus the comparison f == oldf fails on Windows only.

[MikhailRyazanov]

After some tracing through the code on Windows (without a C compiler, but this warning appears before the compilation step), I've found that basically distutils.filelist.FileList.sort()

setuptools/setuptools/_distutils/filelist.py

Lines 65 to 70 in 9c4d383

	def sort(self) -> None:
	# Not a strict lexical sort!
	sortable_files = sorted(map(os.path.split, self.files))
	self.files = []
	for sort_tuple in sortable_files:
	self.files.append(os.path.join(*sort_tuple))

receives both gnvoerk/lib/say.pyx and gnvoerk\lib\say.pyx. Then os.path.split and os.path.join convert them to
gnvoerk/lib\say.pyx and gnvoerk\lib\say.pyx correspondingly, indeed producing a mess. The subsequent tools thus treat them as different files at different paths, with gnvoerk/lib not matching the expected gnvoerk\lib.

Changing

sortable_files = sorted(map(os.path.split, self.files))

to

sortable_files = sorted(map(os.path.split, map(os.path.normpath, self.files)))

eliminates the problem. But I'm not sure that this is the best place to normalize the paths: perhaps they must be normalized in all preceding tools that add to the list of files (at least in _distutils.Extension.__init__() but maybe also in some other places).

As a possible workaround, I've found that converting the paths specified in the sources argument of Extension in setup.py to the platform conventions (that is, using [os.path.normpath('gnvoerk/lib/say.pyx')]) helps. However:

• This contradicts the documentation: “list of source filenames, relative to the distribution root (where the setup script lives), in Unix form (slash-separated) for portability” (bold is mine).
• Therefore might break in other Setuptools versions.
• Cannot be used in pyproject.toml.

So this is definitely a bug and should be corrected in future versions. But a robust workaround for previous versions is also needed.

[MikhailRyazanov]

Some additional findings about the bug:

1. It is not related to build isolation (as long as Extension is used).
2. It doesn’t depend on *.pyx in MANIFEST.in.
3. It was present at least in Setuptools 66.1.0 (I haven’t looked at earlier versions, since they don’t work with Python ⩾3.12).

Regarding a workaround, Setuptools 72.2.0 started supporting “Pathlike objects” in sources, and wrapping a Unix-like path in pathlib.Path (example) indeed works fine on all tested platforms (including Windows). So if this feature is not planned to be deprecated and removed, it’s probably the most reasonable workaround (although still not for pyproject.toml).