"Portable" version ?

[EmmanuelCharpentier]

Somewhat related to this issue

The current (i.e. Sagemath-8.1, decembre 2017) installer cannot be used if the current user doesn't have Administrator rights.

This is unlikely to happen in "normal" situations in academia (researchers have control of their machines, and so do students with their own machines).

But it can happen in "the industry", where IT Depts may be somewhat anal-retentive about what can be connected to their network ; they may or may not be right (they may have to protect sensitive resources, such as medical records...), and, anyway, they may not be able to give administrative rights even when they think they should (i. e. they have to follow policies set by less-than-enlightened managers...).

I may have to solve the problem for my, since I'm supposed to change jobs soon, and my next department has a strict IT policy : Windows 7 without administrative rights, even for researchers. So I'm starting to kiss my Linux installation goodbye (after 16 years...).

But in my new unit, end-users can use non-vetted applications as long as they do not require administrative rights for installation (security ? go figure...). I understand that, in the Windows world, this is called a "portable" version.

So I am currently checking that Sagemath can be compiled from source by an user without administrative rights. So far, it seems so (but it's godawful slow... more on this elsewhere).

So it would be interesting for people in such a predicament to have either a "portable installer" (or a switch recognized by the current installer) allowing the unpacking of a Sage tree (and possibly a couple of shortcuts allowing invocation) without administrative rights.

A possible, rougher, alternative may be a simple tarball (or, more usual in the Windows world, a zip file) of such a tree.

Is that

• possible, and
• not requiring a huge work ?

[GitHubRulesOK]

I am using the windows binary in portable mode i.e. there is no need for an installer.

Main reason for windows users is to not to foul the machine or registry with applications that think they are the only god given solution to our prayers.

My main prayer is don't mess with my system DO NOT ADD yourself to MY HOME directory it is a no go zone, this is a gripe that many administrators will reject sagemath as invading the master area that is for system use only (end rant)

Portable means usually on any drive other than C: so it is a nightmare to get posix in Cygwin to play ball especially with the need to translate a two letter drive moniker to about 10 letters that are meaningless to any scripting system known to windows e.g /cygdrive/d/

Just be prepared that those two principles of sagemath will cause untold grief (along with the daft idea to have a root that has a space and version number.)

[embray]

I forgot about this issue (perhaps since the phrasing is slightly odd) but since v0.4 of the Windows installer it can be installed on a per-user basis to custom locations and it is also possible via the installer to select the location one wants it to use as your "home directory" (which gets mounted in the Cygwin system as /home/sage in order to avoid issues with odd Windows paths in $HOME that some software doesn't handle well otherwise).

If there is a specific bug or issue please provide a detailed explanation and how to reproduce it in a new issue.

[GitHubRulesOK]

Hi embray no specific issue, I do understand that a la windows is totally different to per *nix but most windows users expect that a call to an application will present a gui or more importantly for tex users SageMath (with SageTeX) is often desired to function as a single CLI call without the need for a console.

The usual requirement is that at a native (un elevated) cmd prompt simply entering sage \path to file\example.sagetex.sage should invoke a sage.exe and function "magically" dropping the results in the given location (not in some remote directory associated with system files) I do understand that by pre setting my "home" to the given location as a default can result in the desired result but that seems to be an unnecessary kludge that could be avoided. Equally the circuitous need to call minty to call bash to call sage to call python to call sagemath is fraught with default misdirrections and syntax failures

In short what is needed is a simple .exe that can work behind the scenes to use the variety of "odd" windows path prefixes to become the default location for sage/python/sagemath to work with file input/output especially if there are ./relative/files to that location

[EmmanuelCharpentier]

A possible use case (of utility but to a small fraction of Windows users) of a Sagemath.exe wrapper would be to allow the use of the Win32 version of emacs and sage-shell-mode : the latter use a Windows call that needs a Win32 executable, and does not accept a script. Other marginal use cases may exist.

[GitHubRulesOK]

I built this one liner for TeXstudio and TeXworks should also work if emacs can -shell-escape to cmd however it is the worst kludge I have ever had to write since I was running into dozens of lines of code trying to working around all these issues

https://tex.stackexchange.com/a/472964/170109

It was only alpha tested by me in TeXworks and beta tested by OP in TeXstudio and I probably could improve with a -nodotsage parameter and it frequently is flaky outside the tex editor hence the need for a proper solution.

[embray]

I think what you want is #13.

[embray]

If you want to just run the sage/python interpreter as a headless executable you can also do something as discussed here: https://ask.sagemath.org/question/39742/make-pycharm-recognise-the-sage-python-interpreter/?answer=40220#post-id-40220

The only thing that kind of stinks is that the SAGE_ROOT and SAGE_LOCAL environment variables, at a minimum, must be set correctly, though there have been some recent upstream changes in Sage (e.g. #27191 #27196, among others) to fix this, so it would be possible to just run Sage's Python interpreter directly and 'import sage'.

That said, the main sage executable is actually just a shell script, so one still needs to go through that depending on what you want to do. Since it's just a shell script you can't execute it directly as a Windows executable. You have to run the bash.exe directly with the path the script, and it should be a login shell bash.exe -l or else some environment variables won't be set properly.

[embray]

It might help if you explained in exact terms exactly what you wanted to accomplish, what you tried, what result you expected, and what result you got instead. That way I could offer suggestions and/or solutions.