[PATCH] distutils-r1: Move egg-base to ${BUILD_DIR}/egg-info and prepend to PYTHONPATH

[Mike Gilbert]

This resolves a testing failure in dev-python/cryptography-1.6.1.

cryptography.hazmat.backends._available_backends() scans the available
setuptools entry_points, and so depends on having a valid
egg-info/entry_points.txt file available.

Without this PYTHONPATH update, it uses the egg-info from ${S}, which is not
valid on Linux systems as shipped from upstream.

I move egg-base to a subdirectory of ${BUILD_DIR} to avoid adding ${BUILD_DIR}
to PYTHONPATH. This seems less likely to randomly break other packages.

--- a/eclass/distutils-r1.eclass
+++ b/eclass/distutils-r1.eclass
@@ -362,7 +362,7 @@
build-scripts = %(build-base)s/scripts

[egg_info]
- egg-base = ${BUILD_DIR}
+ egg-base = ${BUILD_DIR}/eggs

# this is needed by distutils_install_for_testing since
# setuptools like to create .egg files for install --home.
@@ -397,9 +397,9 @@
# egg-base in esetup.py). This way, we respect whatever's in upstream
# egg-info.
_distutils-r1_copy_egg_info() {
- mkdir -p "${BUILD_DIR}" || die
+ mkdir -p "${BUILD_DIR}/eggs" || die
# stupid freebsd can't do 'cp -t ${BUILD_DIR} {} +'
- find -name '*.egg-info' -type d -exec cp -pr {} "${BUILD_DIR}"/ ';' || die
+ find -name '*.egg-info' -type d -exec cp -pr {} "${BUILD_DIR}/eggs"/ ';' || die
}

# @FUNCTION: distutils-r1_python_compile
@@ -605,7 +605,7 @@
fi
local BUILD_DIR=${BUILD_DIR}/build
fi
- local -x PYTHONPATH="${BUILD_DIR}/lib:${PYTHONPATH}"
+ local -x PYTHONPATH="${BUILD_DIR}/eggs:${BUILD_DIR}/lib:${PYTHONPATH}"

if [[ ! ${DISTUTILS_SINGLE_IMPL} ]]; then
local -x TMPDIR=${T}/${EPYTHON}

[W. Trevor King]

Post by Mike Gilbert
This resolves a testing failure in dev-python/cryptography-1.6.1.
cryptography.hazmat.backends._available_backends() scans the
available setuptools entry_points, and so depends on having a valid
egg-info/entry_points.txt file available.

This sounds like the issue fixed by my Setuptools patch [1,2]. If I
can reproduce the test failure and confirm that my Setuptools patch
fixes it, can we use my patch when building Setuptools until it lands
upstream?

Cheers,
Trevor

[1]: https://bugs.gentoo.org/show_bug.cgi?id=524322
[2]: https://bitbucket.org/pypa/setuptools/pull-request/85/egg_info-search-egg-base-for-files-to-add/diff

[Mike Gilbert]

Post by W. Trevor King

Post by Mike Gilbert
This resolves a testing failure in dev-python/cryptography-1.6.1.
cryptography.hazmat.backends._available_backends() scans the
available setuptools entry_points, and so depends on having a valid
egg-info/entry_points.txt file available.

This sounds like the issue fixed by my Setuptools patch [1,2]. If I
can reproduce the test failure and confirm that my Setuptools patch
fixes it, can we use my patch when building Setuptools until it lands
upstream?

That looks related, but I'm not sure it would resolve the problem with
dev-python/cryptography.

Would you mind testing that to confirm? You would want to install a
copy of setuptools with your patch applied, remove RESTRICT=test in
cryptography-1.6.1, and then run the tests via the ebuild.

[Mike Gilbert]

Post by Mike Gilbert

Post by W. Trevor King

Post by Mike Gilbert
This resolves a testing failure in dev-python/cryptography-1.6.1.
cryptography.hazmat.backends._available_backends() scans the
available setuptools entry_points, and so depends on having a valid
egg-info/entry_points.txt file available.

This sounds like the issue fixed by my Setuptools patch [1,2]. If I
can reproduce the test failure and confirm that my Setuptools patch
fixes it, can we use my patch when building Setuptools until it lands
upstream?

That looks related, but I'm not sure it would resolve the problem with
dev-python/cryptography.
Would you mind testing that to confirm? You would want to install a
copy of setuptools with your patch applied, remove RESTRICT=test in
cryptography-1.6.1, and then run the tests via the ebuild.

...

Oh, my reading comprehension is not so good at the moment; I realized
you just offered to do exactly that.

I would certainly consider applying a patch to setuptools to resolve
it, though I would prefer upstream to accept it first. I don't want to
end up carrying it forever.