[BUG] propagating egg.info/SOURCES.txt despite being excluded via MANIFEST.in

[jamesbraza]

setuptools version

setuptools==71.1.0

Python version

3.12.4

OS

macOS Sonoma 14.5

Additional environment information

build==1.2.1

Description

I have a MANIFEST.in that looks like this:

# Ignore .gitignore and requirements files
exclude [.r]*
# Ignore .github and tests directories
recursive-exclude [.t]* *
# Exclude all eggs
global-exclude *.egg-info/*

When I editably install, its SOURCES.txt looks like this, and it looks great:

LICENSE
MANIFEST.in
README.md
pyproject.toml
src/package/__init__.py
src/package/foo.py
src/package/py.typed

Next, when I run python -m build --sdist, I get the following output:

* Creating isolated environment: virtualenv+pip...
* Installing packages in isolated environment:
  - setuptools>=64
  - setuptools_scm>=8
* Getting build dependencies for sdist...
running egg_info
writing src/package.egg-info/PKG-INFO
writing dependency_links to src/package.egg-info/dependency_links.txt
writing requirements to src/package.egg-info/requires.txt
writing top-level names to src/package.egg-info/top_level.txt
reading manifest template 'MANIFEST.in'
adding license file 'LICENSE'
writing manifest file 'src/package.egg-info/SOURCES.txt'
* Building sdist...
running sdist
running egg_info
writing src/package.egg-info/PKG-INFO
writing dependency_links to src/package.egg-info/dependency_links.txt
writing requirements to src/package.egg-info/requires.txt
writing top-level names to src/package.egg-info/top_level.txt
reading manifest template 'MANIFEST.in'
adding license file 'LICENSE'
writing manifest file 'src/package.egg-info/SOURCES.txt'
running check
creating package-6.4.2.dev1+gabdd294.d20240723
creating package-6.4.2.dev1+gabdd294.d20240723/src
creating package-6.4.2.dev1+gabdd294.d20240723/src/package
creating package-6.4.2.dev1+gabdd294.d20240723/src/package.egg-info
copying files to package-6.4.2.dev1+gabdd294.d20240723...
copying LICENSE -> package-6.4.2.dev1+gabdd294.d20240723
copying MANIFEST.in -> package-6.4.2.dev1+gabdd294.d20240723
copying README.md -> package-6.4.2.dev1+gabdd294.d20240723
copying pyproject.toml -> package-6.4.2.dev1+gabdd294.d20240723
copying src/package/__init__.py -> package-6.4.2.dev1+gabdd294.d20240723/src/package
copying src/package/foo.py -> package-6.4.2.dev1+gabdd294.d20240723/src/package
copying src/package/py.typed -> package-6.4.2.dev1+gabdd294.d20240723/src/package
copying src/package/version.py -> package-6.4.2.dev1+gabdd294.d20240723/src/package
copying src/package.egg-info/SOURCES.txt -> package-6.4.2.dev1+gabdd294.d20240723/src/package.egg-info
Writing package-6.4.2.dev1+gabdd294.d20240723/setup.cfg
Creating tar archive
removing 'package-6.4.2.dev1+gabdd294.d20240723' (and everything under it)
Successfully built package-6.4.2.dev1+gabdd294.d20240723.tar.gz

Please note that it copies the .egg-info/SOURCES.txt. This is not supposed to happen, as I excluded it as part of the global-exclude in my MANIFEST.in.

What is interesting is all other .egg-info files were not copied, just SOURCES.txt was copied. This is why I think this is a bug

Expected behavior

I expect the .egg-info/SOURCES.txt to be excluded as that was specified in MANIFEST.in

How to Reproduce

See above

Output

See above

[abravalheri]

Hi @jamesbraza, I just to align expectations: I think it is unlikely the behaviour you requested is going to be implemented soon, unless a member of the community contributes with PRs and tests in a way that is backwards compatible.

The reason for that is because .egg-info is one of the aspects of setuptools that I see as going away at some point, so for now the priority is to untangle egg_info from the other parts of setuptools.

[jaraco]

If I recall correctly, Setuptools' (current) design is to write out a manifest of files, based on MANIFEST.in to SOURCES.txt. Without that manifest, setuptools wouldn't know in the sdist which sources to include in the build (as it no longer has the git metadata or other context that would have come from the source repo). So it needs to store that somewhere.

As abravalheri points out, we could potentially revisit that approach, but for now it's not an easy "fix". It'll require revisiting the design, something that's almost certainly not worth doing until after removing reliance on .egg-info.