Current code assumes that CBUILD is always the same as CHOST, however it
is desirable to allow cross compiling into multilib sysroots, where
obviously the assumed condition does not hold anymore. To fix this,
let's override CBUILD only if original CHOST and CBUILD are equal, i.e.
we are not cross-compiling.
This is intended to be set by the user when using ebuilds that may
have unknown implementations in PYTHON_COMPAT. The assumption is
that the ebuilds are intended to be used within multiple contexts
which can involve revisions of this eclass that support different
Python implementations.
Allow two special values in the implementation patterns for
_python_impl_matches(): -2 to indicate all Python 2-compatible
implementations, and -3 to indicate all Python 3-compatible
implementations. Both of those values are implemented using
the python_is_python3 function.
This is mostly meant to make it easier and more fool-proof to write
dependencies on backports to Python 2 which in most cases apply to PyPy2
as well.
Introduce a _python_impl_matches() function that commonizes the pattern
matching behavior used throughout python-r1 & python-single-r1. Having
a single implementation makes future extensions much easier.
Allow specifying the relative package destination using the dot-notation
used by Python itself (e.g. 'foo.bar') in addition to the directory form
('foo/bar'). Since dot can not be used in Python package names, this
change is backwards-compatible.
Clearly indicate that python_moduleinto can be safely called outside
of the environment with Python interpreter established, and that
a single call can set the correct relative path for multiple different
implementations.
Prefix the _clean_egg_info function with an appropriate namespace,
and document its purpose with eclassdoc format. Be more verbose
on the exact problem being solved; remove URL to old upstream bug
tracker that no longer exists.
Add a check for *-nspkg.pth files indicating implicit setuptools
namespace hack. While they kept namespaces somewhat working without
requiring explicit support in ebuilds, they were unreliable. They
frequently required additional hacks (distutils_install_for_testing) to
get the tests working, and they have proven even more broken for Python
3.5+.
For this reason, those files were deprecated in favor of proper,
explicit namespace support. If they are found to exist, the developer
should ensure to remove them to avoid issues.