|Summary:||[Future EAPI] query functions for ebuild-defined variables|
|Product:||Gentoo Hosted Projects||Reporter:||Patrick McLean <chutzpah>|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
Description Patrick McLean 2019-12-05 22:56:32 UTC
It would be useful to have a way to query various variables from eclasses, so the eclasses can do some sanity checking in the ebuild. My initial suggestion is a way to query PROPERTIES and *DEPEND, a helper function would be more than sufficient. For PROPERTIES it would be sometimes useful from an eclass to check if an ebuild is a live ebuild or not, which would allow some useful behaviour changes (for example the distutils-r1.eclass could get the versioning information for the installed python package from git metadata for live ebuilds). For *DEPEND, I suggest "in_depstring <string> <atom>" to see if an atom is in the merged dependency string for an ebuild. One recent example of where this might be useful (once again in distutils-r1.eclass). In distutils-r1_python_prepare_all (like src_prepare) we could do this: if grep -E -q "(import .*setuptools|from setuptools import)" setup.py \ && ! in_depstring BDEPEND 'dev-python/setuptools'; then die "Package's setup.py uses setuptools, but setuptools not in BDEPEND" fi
Comment 1 Ulrich Müller 2020-10-25 17:58:09 UTC
Questions: 1. USE-conditional expressions in *DEPEND etc. should be evaluated, I suppose? 2. How would groups like "|| ( )" be handled? 3. How exactly should dependency specifications be matched? For example, if the ebuild has >=dev-python/setuptools-50.3.0 in *DEPEND, would dev-python/setuptools match (and vice versa)? 4. Should slot dependencies and USE dependencies be included in the matching? TBH, I'd rather see a proof-of-concept implementation before we consider this for the next EAPI.