Issues like #22628 remind me of an idea I've had before for improving the situation with the otherwise difficult to maintain and unwieldy sage.env module.

ISTM that almsot all the data in that file could be read from a plain text file format (either an ini-like file or JSON, for example). Furthermore, this file could be generated, or updated, at install time for spkgs (including Sage itself). This would help make the growing number of (sometimes contentious) spkg-specific variables (CONWAY_POLYNOMIALS_DATA_DIR, GRAPHS_DATA_DIR, GAP_ROOT_DIR, SINGULAR_SO, etc.) more manageable.

If each spkg is allowed its own "section" in this config file, the installers for those spkgs could be allowed to manage the data in that section as well, which is sometimes platform-specific. It is also data that is usually more accessible at install-time of that package than it is to Sage at runtime. For example, #22628 raises a tricky issue about how to set SINGULAR_SO. If the correct path to SINGULAR_SO were written to a config file at install time, that would push all platform-specific logic about how to set that path to the spkg-install script, and out of sage.env. For system packagers, such as for Gentoo or Debian, they would be free to write whatever they want in this config file, and it would free them having to do as much patching to sage.env and possibly other files.

I have some idea how this might work, so I'm willing to cook up a prototype if it doesn't sound like a terrible idea.

Depends on #27040

CC: @kiwifb @jdemeyer @mkoeppe @timokau

Component: porting

Issue created by migration from https://trac.sagemath.org/ticket/22652