[gentoo-portage-dev] [PATCHES] setup.py install for Portage

[Michał Górny]

Hello, everyone.

Here is a rebase of my recent work on bringing setup.py install for
Portage.


About the patches:

(1) teaches the self-update function to deal with PORTAGE_PYM_PATH that
contains more packages than Portage itself. In particular, it makes it
copy packages of Portage only rather than everything found in 'pym' :).

(2) makes PORTAGE_PYM_PATH contain wherever Portage is loaded from
rather than 'pym' subdirectory of PORTAGE_BASE_PATH. This makes the code
work well when 'pym' directory is removed.

(3) makes sure that all important test files are suffixed with .py so
that they are installed by setup.py without extra hackery.

(4) fixes all the remaining issues with tests, allowing them to be run
on the installed copy of Portage.

(5) replaces the Makefiles with setup.py. It's distutils with a few
extensions -- mostly making it possible to install scripts to multiple
locations, install data files recursively and override all the paths.

(6) updates .travis.yml to run tests using setup.py, and also try
installing and re-running tests after install.

I will follow this thread with updated ebuild.


About the new install layout:

1. /usr/lib/portage/pym no longer exists. Python files are installed
directly to site-packages for each implementation (by default).

2. /usr/lib/portage/bin no longer contains copies of the scripts that
are installed to /usr/bin and /usr/sbin.

3. All Python scripts have proper shebangs set by distutils. To fit this
with how distutils usually works and how the eclass expects it to be
done, my ebuild had done a few more changes:

3a. all programs from /usr/sbin are moved to /usr/bin, and all programs
in /usr/bin are wrapped.

3b. The Portage internal tools are moved from /usr/lib/portage/bin
to /usr/lib/portage/${EPYTHON} so that no Python mismatch is possible.

3c. /usr/lib/portage/bin became a symlink for external tool
compatibility. It uses the 'last' Python implementation as chosen
by distutils-r1.


I have tested these changes for a while and I think Portage itself can
handle them well. However, some of the external tools overrelying on
Portage itself can be broken, eix in particular.

In particular, tools that want to play with Portage internals need to
export proper PORTAGE_BIN_PATH and PORTAGE_PYM_PATH before spawning
them. The correct values can be obtained using portageq:

  $ portageq envvar PORTAGE_BIN_PATH
  /usr/lib/portage/python3.4
  $ portageq envvar PORTAGE_PYM_PATH
  /usr/lib64/python3.4/site-packages


Please look through the patches and test at will :). Thanks.

--
Michał Górny