whl built from 16.14.0 release tarbball turns out empty

[nieder]

Building 16.14.0 (macOS), I get an empty whl with only the metadata files inside path-16.14.0.dist-info directory.

For the record, the last time I tried to build path (12.0.1) using the setup.py, it built fine.

Here's my build log:

/sw/bin/python3.10 -m build --wheel --no-isolation --skip-dependency-check
* Building wheel...
running bdist_wheel
running build
installing to build/bdist.macosx-10.14-x86_64/wheel
running install
running install_egg_info
running egg_info
writing path.egg-info/PKG-INFO
writing dependency_links to path.egg-info/dependency_links.txt
writing requirements to path.egg-info/requires.txt
writing top-level names to path.egg-info/top_level.txt
listing git files failed - pretending there aren't any
reading manifest file 'path.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
adding license file 'LICENSE'
writing manifest file 'path.egg-info/SOURCES.txt'
Copying path.egg-info to build/bdist.macosx-10.14-x86_64/wheel/path-16.14.0-py3.10.egg-info
running install_scripts
creating build/bdist.macosx-10.14-x86_64/wheel/path-16.14.0.dist-info/WHEEL
creating '/sw/build.build/path-py310-16.14.0-1/path-16.14.0/dist/tmp1ipt1udg/path-16.14.0-py3-none-any.whl' and adding 'build/bdist.macosx-10.14-x86_64/wheel' to it
adding 'path-16.14.0.dist-info/LICENSE'
adding 'path-16.14.0.dist-info/METADATA'
adding 'path-16.14.0.dist-info/WHEEL'
adding 'path-16.14.0.dist-info/top_level.txt'
adding 'path-16.14.0.dist-info/RECORD'
removing build/bdist.macosx-10.14-x86_64/wheel
Successfully built path-16.14.0-py3-none-any.whl

These are the contents of the resulting wheel:

[Bubble:/sw/build.build/path-py310-16.14.0-1/path-16.14.0/dist] nieder $ zipinfo pa*.whl
Archive:  path-16.14.0-py3-none-any.whl
Zip file size: 4331 bytes, number of entries: 5
-rw-r--r--  2.0 unx     1023 b- defN 24-Jun-17 13:05 path-16.14.0.dist-info/LICENSE
-rw-r--r--  2.0 unx     6394 b- defN 24-Jun-17 13:05 path-16.14.0.dist-info/METADATA
-rw-r--r--  2.0 unx       92 b- defN 24-Jun-17 13:05 path-16.14.0.dist-info/WHEEL
-rw-r--r--  2.0 unx        1 b- defN 24-Jun-17 13:05 path-16.14.0.dist-info/top_level.txt
-rw-rw-r--  2.0 unx      380 b- defN 24-Jun-17 13:05 path-16.14.0.dist-info/RECORD

I have setuptools-59.6.0 and setuptools-scm-6.4.2, both of which fulfill the deps as listed in pyproject.toml. I need path on the way to upgrading setuptools (which it needs for tests).

[nieder]

I did some triaging of releases, and 16.10.0 builds correctly and passes tests, while 16.10.1 is the first release that builds an empty wheel.

[jaraco]

That's interesting. Using pip wheel and build isolation, the wheel builds fine from sdist:

 draft 🐚 pip download --no-deps --no-binary path path
Collecting path
  Downloading path-16.14.0.tar.gz (50 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 50.1/50.1 kB 1.6 MB/s eta 0:00:00
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Saved ./path-16.14.0.tar.gz
Successfully downloaded path
 draft 🐚 pip wheel path-16.14.0.tar.gz
Processing ./path-16.14.0.tar.gz
  File was already downloaded /Users/jaraco/draft/path-16.14.0.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: path
  Building wheel for path (pyproject.toml) ... done
  Created wheel for path: filename=path-16.14.0-py3-none-any.whl size=25465 sha256=b91321af1639d57bf5025f0b3cd1aaca55bf4f25ccf5a750ee7d647e5688b798
  Stored in directory: /Users/jaraco/Library/Caches/pip/wheels/4aec/44/6912a1ce61e0207fc5c15342eb6742301a3ec7d724a359c34d
Successfully built path
 draft 🐚 unzip path-16.14.0-py3-none-any.whl
Archive:  path-16.14.0-py3-none-any.whl
  inflating: path/__init__.py        
  inflating: path/__init__.pyi       
  inflating: path/classes.py         
  inflating: path/classes.pyi        
  inflating: path/masks.py           
  inflating: path/matchers.py        
  inflating: path/matchers.pyi       
  inflating: path/py.typed           
  inflating: path/compat/py38.py     
  inflating: path-16.14.0.dist-info/LICENSE  
  inflating: path-16.14.0.dist-info/METADATA  
  inflating: path-16.14.0.dist-info/WHEEL  
  inflating: path-16.14.0.dist-info/top_level.txt  
  inflating: path-16.14.0.dist-info/RECORD  

I'll see if I can replicate with the specific instructions provided.

[jaraco]

Indeed, if I'm using Python 3.10 and Setuptools 59.x and setuptools_scm, I get the reported behavior:

 path-16.14.0 🐚 py -3.10 -m pip-run setuptools==59.6.0 setuptools_scm==6.4.2 build -- -m build --wheel --no-isolation --skip-dependency-check

[notice] A new release of pip is available: 24.1.1 -> 24.1.2
[notice] To update, run: python3.10 -m pip install --upgrade pip
* Building wheel...
running bdist_wheel
running build
installing to build/bdist.macosx-14-arm64/wheel
running install
running install_egg_info
running egg_info
listing git files failed - pretending there aren't any
writing manifest file 'path.egg-info/SOURCES.txt'
Copying path.egg-info to build/bdist.macosx-14-arm64/wheel/path-16.14.0-py3.10.egg-info
running install_scripts
creating build/bdist.macosx-14-arm64/wheel/path-16.14.0.dist-info/WHEEL
creating '/Users/jaraco/draft/path-16.14.0/dist/tmpnbyxpkd3/path-16.14.0-py3-none-any.whl' and adding 'build/bdist.macosx-14-arm64/wheel' to it
adding 'path-16.14.0.dist-info/LICENSE'
adding 'path-16.14.0.dist-info/METADATA'
adding 'path-16.14.0.dist-info/WHEEL'
adding 'path-16.14.0.dist-info/top_level.txt'
adding 'path-16.14.0.dist-info/RECORD'
removing build/bdist.macosx-14-arm64/wheel
Successfully built path-16.14.0-py3-none-any.whl

I observe that the pyproject.toml does declare a dependency on setuptools>=61.2. That dependency was added for some reason, though I'm not sure what.

If I change the command to use setuptools 61.2.0 instead of 59.6.0, the problem goes away, so that's almost certainly the cause. By using --no-isolation and --skip-dependency-check, you're adopting incompatible build tooling, so it's probably not a big surprise when the build doesn't complete properly.

I see that dependency was bumped in https://github.com/jaraco/skeleton/blame/7ad4f2fa9fb2b030d3ecc231fc24de181705622d/pyproject.toml, presumably because setuptools 61.1 and earlier has limited support for pyproject.toml.

I see that Setuptools 61.2 didn't introduce pyproject.toml support, but it did fix some bugs about it. It's possible that 61.2 was selected to include pyproject.toml support but perhaps later to include the bug fixes.

Aha, I can see now where ini2toml defines the lower bound for supported setuptools to support the new toml features.

So I guess it boils down to - you need to either upgrade setuptools or pin to the older path that can build with the older setuptools.

Is there anything else you think this project should do?

[nieder]

Thanks for the followup debugging. If I follow correctly, although 16.14.0 declares a dep on setuptools 56 in pyproject.toml, it should have been upgraded to 61.2 (which happened for path-16.15.0).

Since this is a case of needing to update local deps, this can be closed.

[jaraco]

I see now that the aforementioned commit was incorrect. I've adjusted it to point to the correct commit in the skeleton. Looking at that same commit in this repo (f4529af), I can confirm that the change was only introduced in path 16.15, as you described.

So yes, it seems that path was implicitly dependent on a later version of Setuptools. Since you bisected the change to observe that the regression happened with path 16.10.1, I dug a little deeper and searched the differences are here: v16.10.0...v16.10.1. The change that introduced the regression is almost certainly 63535c6, which removed configuration to instead rely on a Setuptools feature that was probably only introduced in a later version, and only coincidentally fixed when the config was moved to pyproject.toml and the minimum version bumped.

Thanks for your help understanding and uncovering the issue, as it might also affect other skeleton-based projects. For this project, as you say, the v16.15.0 release is backward-compatible to v16.10.1, so the recommended fix is simply to upgrade.