Portage crashes and shows no informative error message when executed on another distro after being installed with pip install --user Reproducible: Always Steps to Reproduce: 1. pip install --user portage 2. PYTHONPATH=$HOME/.local/lib/python3.11/site-packages ~/.local/lib/portage/bin/emerge Actual Results: ``` ======== Traceback for invalid call to portage.package.ebuild.config.config.__getitem__ ======== File "/home/daandemeyer/.local/bin/emerge", line 59, in <module> retval = emerge_main() File "/home/daandemeyer/.local/lib/python3.11/site-packages/_emerge/main.py", line 1261, in emerge_main emerge_config = load_emerge_config(action=myaction, args=myfiles, opts=myopts) File "/home/daandemeyer/.local/lib/python3.11/site-packages/portage/proxy/objectproxy.py", line 31, in __call__ return result(*args, **kwargs) File "/home/daandemeyer/.local/lib/python3.11/site-packages/_emerge/actions.py", line 2900, in load_emerge_config emerge_config.trees = portage.create_trees(trees=emerge_config.trees, **kwargs) File "/home/daandemeyer/.local/lib/python3.11/site-packages/portage/__init__.py", line 714, in create_trees "bintree", binarytree, pkgdir=mysettings["PKGDIR"], settings=mysettings File "/home/daandemeyer/.local/lib/python3.11/site-packages/portage/package/ebuild/config.py", line 3116, in __getitem__ return self._getitem(key) ^^^^^^^^^^^^^^^^^^ File "/home/daandemeyer/.local/lib/python3.11/site-packages/portage/package/ebuild/config.py", line 3193, in _getitem raise KeyError(mykey) KeyError: 'PKGDIR' ```
I see the problem. It works when installed to a venv because sys.prefix returns the path to the venv, but the environment used by "pip install --user" is not a venv. We'd probably need to do something based on __file__ instead.
I'm not sure that we can fix this properly. I don't want to rely on __file__ to go from foo/lib/python3.XX/site-packages/portage/const.py to just foo because this scheme can vary between platforms and distributions. pip has tons of code just to figure this stuff out. Distribution-managed environments and virtual environments are really the only sane options anyway. Unlike virtual environments, the environment used by "pip install --user" is designed to be used for installation of different modules, but that will inevitably lead to conflicts. It can even break your system-wide modules. This is why Gentoo slaps a big warning on it: > $ pip install --user . > error: externally-managed-environment > > × This environment is externally managed > ╰─> > The system-wide Python installation in Gentoo should be maintained > using the system package manager (e.g. emerge). > > If the package in question is not packaged for Gentoo, please > consider installing it inside a virtual environment, e.g.: > > python -m venv /path/to/venv > . /path/to/venv/bin/activate > pip install mypackage > > To exit the virtual environment, run: > > deactivate > > The virtual environment is not deleted, and can be re-entered by > re-sourcing the activate file. > > note: If you believe this is a mistake, please contact your Python > installation or OS distribution provider. You can override this, at > the risk of breaking your Python installation or OS, by passing > --break-system-packages. > hint: See PEP 668 for the detailed specification.
