sage.env: Give values from sage_conf precedence over environment variables

[mkoeppe]

This change will make installations of Sage more robust.

Currently,

    /SAGE_ROOT_A/sage -sh -c '/SAGE_ROOT_B/venv/bin/python3 -c "import sage.env; print(sage.env.SAGE_ROOT)"'

will give SAGE_ROOT_A (bad), whereas

    /SAGE_ROOT_A/sage -sh -c '/SAGE_ROOT_B/venv/bin/sage -c "import sage.env; print(sage.env.SAGE_ROOT)"'

will give SAGE_ROOT_B (good).

Similarly to

• Top-level sage script: Unconditionally set SAGE_ROOT #33786 (Top-level sage script: Unconditionally set SAGE_ROOT) and
• sage-env, sage-build-env: No longer allow environment variables CC, CFLAGS, ... to override configured variables #32436 (sage-env, sage-build-env: No longer allow environment variables CC, CFLAGS, ... to override configured variables)

CC: @jhpalmieri @kiwifb

Component: refactoring

Branch/Commit: u/mkoeppe/sage_env__give_values_from_sage_conf_precedence_over_environment_variables @ 4d20b92

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

[mkoeppe]

Description changed:

--- 
+++ 
@@ -12,5 +12,7 @@
 ```
 will give `SAGE_ROOT_B` (good).
 
-Similarly to #33786 (Top-level sage script: Unconditionally set SAGE_ROOT)
+Similarly to 
+- #33786 (Top-level sage script: Unconditionally set SAGE_ROOT) and 
+- #32436 (`sage-env`, `sage-build-env`: No longer allow environment variables CC, CFLAGS, ... to override configured variables)
 

[kiwifb]

comment:2

I am a bit dubious when I see the title. I don't think you should override environment variables unless you absolutely have to.

What I think the ticket is about, and feel free to correct me, is that some variables, needed for sage's own operation, should be internal to sage and not exposed to be modifiable by environment variables. They should be private. If my interpretation is correct we need to start with a list of those variables that should be private.

[mkoeppe]

comment:3

Replying to @kiwifb:

What I think the ticket is about [...] is that some variables, needed for sage's own operation, should be internal to sage and not exposed to be modifiable by environment variables.

Well, that's a slightly stronger form than what I've written.

In what I wrote, the value would still be taken from the environment if it is not defined in sage_conf.

The stronger form would be fine for me as well.

[kiwifb]

comment:4

Thanks for the clarification. I guess from the point of view of what I have written, that makes all variables in sage_conf private.

From my distro point of view that may mean adding variables there that I did not care to have. Like SAGE_ROOT.

[mkoeppe]

comment:5

The stronger form can be implemented by just adding force=True.

    - ``force`` -- boolean (optional, default is ``False``). If
      ``True``, skip the environment variable and only use the
      fallbacks.

[mkoeppe]

comment:6

Some variables such as UNAME make no sense to even fetch from sage_conf. We could just set the value in sage.env.

[kiwifb]

comment:7

When you say in sage_conf I think of variables in this file https://github.com/sagemath/sage-prod/blob/develop/pkgs/sage-conf/_sage_conf/_conf.py.in - do you mean something else? I am asking because I am not sure where UNAME comes from.

[mkoeppe]

comment:8

Replying to @kiwifb:

When you say in sage_conf I think of variables in this file https://github.com/sagemath/sage-prod/blob/develop/pkgs/sage-conf/_sage_conf/_conf.py.in

Yes

I am asking because I am not sure where UNAME comes from.

It's set in the sage-env script and then again there's the fallback in sage.env.

[kiwifb]

comment:9

So, are you also wanting to cut some redundancies as part of the ticket? I guess it may make sense with some item.

[mkoeppe]

Branch: u/mkoeppe/sage_env__give_values_from_sage_conf_precedence_over_environment_variables

[mkoeppe]

comment:11

Replying to @kiwifb:

So, are you also wanting to cut some redundancies as part of the ticket? I guess it may make sense with some item.

Well, many environment variables set in sage-env are completely useless, but I've been reluctant to remove them in case user scripts make use of them.

But by using force=True we can at least eliminate the useless dataflow from environment variables to sage.env variables

---

New commits:

9997254

sage.env: Do not take UNAME, SAGE_VERSION, SAGE_DATE, SAGE_VERSION_BANNER, SAGE_VENV, SAGE_LIB, SAGE_EXTCODE from environment variables

[mkoeppe]

Commit: 9997254

[kiwifb]

comment:12

Replying to @mkoeppe:

Replying to @kiwifb:

So, are you also wanting to cut some redundancies as part of the ticket? I guess it may make sense with some item.

Well, many environment variables set in sage-env are completely useless, but I've been reluctant to remove them in case user scripts make use of them.

Agree on the uselessness. sage-on-gentoo is sage-env less and so far I haven't had complains. If we had some kind of repo of user scripts, it would be an interesting thing to test.

[sagetrac-git]

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

4a2fcd5

sage.env: Clarify current behavior of var

[sagetrac-git]

Changed commit from 9997254 to 4a2fcd5