Change some string variables in env.py to methods

[mkoeppe]

This ticket changes some of the string variables in src/env.py pointing to paths to methods returning a Path.

[mkoeppe]

The code using MULTILIB was introduced in #27230.

[mkoeppe]

As noted in #27230, another version of this code is in find_library in src/sage/misc/compat.py, which claims to provide better platform compatibility compared to ctypes.util.find_library (on Cygwin and macOS). It should be checked whether this code (introduced in 2017, for Python 2.7) is still necessary.

[gh-tobiasdiez]

I have a few questions:

1. Should MULTILIB still be used?
2. If yes, what's the correct way to use it? In ​https://github.com/sagemath/sage/commit/edfb14de609040b990546bd07331add3bb0711fc the behavior was changed: before it was appended to usr/lib but after this commit it is appended to SAGE_LOCAL/lib. Was this change on purpose?

[mkoeppe]

On a quick search, I have not found any evidence for the existence of the MULTILIB variable, and on the ticket where it was introduced there is no discussion of testing on any specific multiarch platforms. My guess is that this was never working. Let's get rid of it and then just test it on our supported platforms.

[mkoeppe]

This ticket needs a branch

[gh-tobiasdiez]

Ready for review.

---

New commits:

​13216c1

Fix multiarch for shared libraries

[mkoeppe]

Too many changes on one ticket - interface, implementation, ...

This places an unnecessary burden on reviewers.

Also, it seems that this ticket tries to establish a new convention get_... for things in sage.env, including a new function get_sage_local.

As I said on another ticket - we already have a place for more structured access to system information - that's sage.feature. Please don't create another place in sage.env

[gh-tobiasdiez]

I'm sorry that the changes are bigger. However, I mostly rewrote the _get_shared_lib_filename method, and the other changes are only a consequence of these changes. For example, the new implementation returns only a path that exists, so the additional check in singular.pyx is no longer necessary. I honestly don't know how I can split this ticket into smaller pieces.

For the get functions, do you suggest to go back to the variable approach? My reason for the get functions was that this access the file path, and thus having getter functions potentially leads to better startup time (e.g. if you don't initialize singular). If you prefer I can of course revert to using variables. For get_sage_local, that was only a minor refactoring since I used it in multiple places. I can make it a private function if desired.

[mkoeppe]

Replying to gh-tobiasdiez:

My reason for the get functions was that this access the file path, and thus having getter functions potentially leads to better startup time (e.g. if you don't initialize singular).

That's a concern that is orthogonal to this ticket, so please don't do it on this ticket.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d9f36dc

Don't use Python 3.8 syntax

[gh-tobiasdiez]

I've now extracted some of the changes to #30901, so that this ticket is now only about the change of interface from variables to methods.

[gh-tobiasdiez]

This is no longer needed.