Currently, any python module officially in Funtoo needs an ebuild, preferably an autogenned ebuild. Once the ebuild exists, then a user can use Portage to install python module dependencies of packages via emerge.

There is a problem with this model, and autogens make things more manageable but do not solve the problem for Python.

In Python, PEP 517 allows for anyone to write their own build/packaging tool, which was done because the default packaging tools for Python have historically not been very good. But now there is an arbitrary number of build/packaging systems Funtoo would need to support. Gentoo has addressed that by adding PEP 517 support to the distutils-r1.eclass and now supports about 10 different new build systems. The distutils-r1.eclass is now over 2000 lines of bash code.

The above challenge may seem like just some additional complexity that we need to overcome, and yes, we could simply follow Gentoo's lead here, however –

THE IDEA OF HAVING EBUILDS FOR PYTHON MODULES IS IN MOST CASES FUNDAMENTALLY WRONG.

The reason for this is that the Python ecosystem is huge and getting one set of golden modules that all work well with each other and with all applications in Portage is never going to be possible. Yet that is exactly the presumption of the current Gentoo approach when it comes to Python module management.

In reality, the best thing one can hope for is a sane set of python modules, selected by an upstream developer, which will work properly with their specific application.

Thus, the correct approach is to set up a venv per application, and have these venvs be managed out-of-band of Portage and ebuilds.

This would also eliminate the immense complexity added to Portage to track all these dependencies.