[gentoo-python] Looking for improvements for python-r1, to support sys-apps/portage better

[Michał Górny]

Hi, everybody.

I've recently worked on writing setup.py for Portage so that we could
start installing it like proper Python package. For my work, I've
written an ebuild that you can find in ::mgorny overlay [1]. Sadly,
a few things don't work properly.

I know I've pretty much screwed up python-r1 and made it overcomplex.
I'm looking for your suggestions how I could improve it, or at least
make my Portage ebuild work :).

The issue is that the Python script wrapping in distutils-r1 has been
designed for the common distutils concept of single scriptdir. However,
in case of Portage we're installing scripts to three different
locations -- one involving subdirectories.

The usual wrapping code assumes that passing --install-scripts= will
cause scripts to be installed in python-exec directory. However,
in Portage this variable isn't used. Even if it were, we wouldn't know
how to split the scripts into original directories afterwards. So I
think we can only do manual wrapping here.

However, the proper is that the script collide once merged to ${D}. We
install to sub-root but it is merged before leaving
distutils-r1_python_install. So we either need to hack that around even
more, or disable parallel install (== make it very slow for Portage).

A few possibilities that come to my mind include:

1. make whole python_install() work on sub-root, merge after leaving
it. This will be an incompatible change since ${D} will have to be
replaced by a custom variable.

2. add some implicit extra script wrapping support. Like
DISTUTILS_SCRIPT_DIRECTORIES=() that can specify additional locations
to look for scripts. Seems a bit overkill for a single case.

Any other ideas?

[1]:http://git.overlays.gentoo.org/gitweb/?p=dev/mgorny.git;a=blob;f=sys-apps/portage/portage-9999.ebuild

-- 
Best regards,
Michał Górny