back up environment on sage startup

[rwst]

The original environment unclobbered by Sage might be needed by subprocesses (e.g. patchbot) so just save it somewhere at the very start.

For the motivation see https://groups.google.com/forum/?hl=en#!topic/sage-devel/1dpr0__-ssw

Component: scripts

Keywords: shell, start, sandbox

Author: Ralf Stephan

Branch/Commit: u/rws/back_up_environment_on_sage_startup @ c611382

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

[rwst]

Branch: u/rws/back_up_environment_on_sage_startup

[rwst]

Author: Ralf Stephan

[rwst]

Commit: 8841032

[rwst]

New commits:

8841032

16377: back up env to SAGE_ROOT/.orig-env

[jhpalmieri]

comment:3

You should never assume that the user can write to SAGE_ROOT.

[rwst]

comment:4

Ah thanks, DOT_SAGE would be indeed better.

[sagetrac-git]

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

6b65eea	copy helper functions from sage-env to sage; backup env to DOT_SAGE
c611382	Merge branch 't/16377/back_up_environment_on_sage_startup' into tmp

[sagetrac-git]

Changed commit from 8841032 to c611382

[jdemeyer]

comment:6

There are several issues:

1. Re-entrancy: when running different Sage processes, the environment of only 1 will be kept.
2. Quoting: The textual output of env is not suitable, since \n characters in environment variables cannot be reconstructed correctly. Assuming you need this for Python, why not use Python to store the environment in a Python pickle for example?
3. Why did you copy the DOT_SAGE stuff to src/bin/sage? Why not simply store the environment inside sage-env?
4. Your code does not support --nodotsage.

And could you please state more precisely which problem this solves?

[jdemeyer]

comment:8

I can't say I understand completely what https://groups.google.com/forum/?hl=en#!topic/sage-devel/1dpr0__-ssw talks about, but this ticket looks like the wrong solution for that problem.

The patchbot simply should not run/compile Sage in a different source tree from what the SAGE_* environment variables point to.

I don't want to say that this ticket is pointless, but it should not be used to fix the patchbot issue you're having.

[jdemeyer]

comment:9

To fix the patchbot issue, why not run the patchbot outside of the Sage environment, as an ordinary Python program?

[rwst]

comment:10

Thanks for the insight. That appears indeed to be the right solution. So the documentation on http://patchbot.sagemath.org/ that wants the user to use sage -patchbot should be changed.

[rwst]

comment:11

Consequently, a ticket is needed to remove the -patchbot argument to Sage.

[vbraun]

comment:12

The handling of the -patchbot switch in src/bin/sage needs to be moved above the "Source sage-env" step, so it is done before the environment is changed. In another ticket, please ;-)

[rwst]

comment:14

Replying to @vbraun:

The handling of the -patchbot switch in src/bin/sage needs to be moved above the "Source sage-env" step, so it is done before the environment is changed. In another ticket, please ;-)

This is now #16390