Python 2 builds broken

[fastcat]

Setup

Package Name: python (or anything that contains python 2 modules)
Package Version: 2.7.15

NAS Model: N/A
NAS Architecture: denverton
DSM version: 6.1

Expected behavior

Should be able to build the python 2.x package, and its components as a dependency of other packages

Actual behavior

Build fails during module install step with error:

error: 'egg_base' must be a directory name (got `src`)

Steps to reproduce

1. Clone current master (b2901ad at the moment)
2. Use the the docker image to try to build the python package

Build log

running install_egg_info
error: 'egg_base' must be a directory name (got `src`)
make[2]: *** [../../mk/spksrc.python-module.mk:31: install_python_module] Error 1
make[2]: Leaving directory '/spksrc/cross/wheel'
make[1]: *** [../../mk/spksrc.depend.mk:44: depend_target] Error 2
make[1]: Leaving directory '/spksrc/spk/python'
make: [../../mk/spksrc.spk.mk:463: arch-denverton] Error 2 (ignored)

I'm trying to wind back to see if I can find a working commit that isn't ancient history. The last time I tried building (which was successful) was 00a880a (December 2018), which is ... quite definitely ancient history. Also I can no longer build that old commit with the current docker image as the partially built copy of python segfaults doing ./python -E -S -m sysconfig --generate-posix-vars during its build.

[fastcat]

So, it seems that trying to build the python spk always fails, but if I try to build rdiff-backup, I can get reasonable results with git bisect:

git bisect start
# good: [ef7ba1f5b9434d39b7657c82af1930e526209360] Redis version 5.0.7 (#3814)
git bisect good ef7ba1f5b9434d39b7657c82af1930e526209360
# bad: [b2901addb90b06d8d5b224ebc5f727a0500a24b1] python3: fix build of python module files (#3911)
git bisect bad b2901addb90b06d8d5b224ebc5f727a0500a24b1
# good: [99e3f6eb0d1473d0e954f1b6d52c6eddc75199ae] comskip: update to 0.82.010
git bisect good 99e3f6eb0d1473d0e954f1b6d52c6eddc75199ae
# good: [787c656b8975dd74449dc92474cc0c0cd439e5c2] chromaprint: update for packaging with ffpmeg 4.2
git bisect good 787c656b8975dd74449dc92474cc0c0cd439e5c2
# good: [c8bedfb518b1f247baf8b4676be2ca2213d75590] python3: upgrade to 3.6.10
git bisect good c8bedfb518b1f247baf8b4676be2ca2213d75590
# bad: [f6e7a96f32a7368f6f8c07a0f6179f3be0a17287] Allow arch-specific level patch to mk build (#3896)
git bisect bad f6e7a96f32a7368f6f8c07a0f6179f3be0a17287
# bad: [2d23bd2ed3dc5386fbc6bbd18d88f4003707577d] python3: update dependencies and requirements
git bisect bad 2d23bd2ed3dc5386fbc6bbd18d88f4003707577d
# first bad commit: [2d23bd2ed3dc5386fbc6bbd18d88f4003707577d] python3: update dependencies and requirements

Which ... isn't too surprising given the git log? The more interesting piece is that b2901ad doesn't seem to have actually fixed it -- #3911 seems to have been incomplete in some way?

In the setuptools changelog, this entry in v42.0.0 looks suspicious: eggs are not supported. But if I downgrade setuptools to the prior release -- 41.6.0 -- then it still fails, so I guess the issue is more complicated than that.

[hgy59]

On my py27 branch (#3648) I got the same error with Wheel updated to version 34.2. A downgrade of cross/wheel to version 33.6 fixed this.

[fastcat]

I wonder if wheel is internally pulling in a too-new version of setuptools?

A recent commit to wheel swapped a dependency on setuptools_scm for setuptools itself: pypa/wheel@510a531. I'm no Python expert, but that starts to look suspicious as at least part of the issue here?