Allow SAGE_LOCAL to be customized

[jdemeyer]

This ticket allows a $SAGE_LOCAL directory different from $SAGE_ROOT/local.

The idea is that #21479 would set $SAGE_LOCAL to the --prefix chosen by the user.

[felixs]

that seems to make sense. but it's dangerous really. SAGE_LOCAL is an internal directory and an implementation detail currently.

if you expose this, users will start expecting stuff in SAGE_LOCAL created by the build process. an ideal build process does not (will not/should not) use SAGE_LOCAL. any transition to fixing this will heavily interfere with user experience (only if they override SAGE_LOCAL, of course).

ok, now i explained why "set prefix==SAGE_LOCAL" is probably not a good idea. and here, an alternative, "expose SAGE_LOCAL", appears to be much worse... hmm

there's a problem here. can you please give some more insight on what you are trying to achieve with the customized SAGE_LOCAL?

thanks

[jdemeyer]

Replying to felixs:

SAGE_LOCAL is an internal directory and an implementation detail currently.

I am not changing that. I still consider it an implementation detail.

can you please give some more insight on what you are trying to achieve with the customized SAGE_LOCAL?

I am allowing Sage to be installed in a custom directory, which is not $SAGE_ROOT/local.

[felixs]

I am allowing Sage to be installed in a custom directory,

SAGE_LOCAL cannot be the installation directory *and* an implementation detail.

but you seem to have your own definition for both these terms, rendering this discussion pointless.

[jdemeyer]

Replying to felixs:

I am allowing Sage to be installed in a custom directory,

SAGE_LOCAL cannot be the installation directory *and* an implementation detail.

The current reality is that $SAGE_LOCAL is the installation directory and an implementation detail. So I am really not changing that.

[felixs]

Replying to jdemeyer:

The current reality

you put "Allow SAGE_LOCAL to be customized" into the title. this (to me) implies that SAGE_LOCAL would become a user controlled variable (see above). i hope not! but is it really your intent?

i figured, that maybe/actually/hopefully you want to introduce prefix (defaulting to $(builddir)/local), then set SAGE_LOCAL=prefix. then do some modifications so the rest of dist can cope with it.

about the title... what about "implement pretend-prefix using SAGE_LOCAL" or "use SAGE_LOCAL to implement pretend-prefix"? (yes, "pretend", because it will look like prefix to the user, while the build process will still write to it).

[mkoeppe]

Jeroen, are you working on this? Which changes should go into this ticket, and which changes into #21479?

[jdemeyer]

Replying to mkoeppe:

Jeroen, are you working on this?

Yes.

Which changes should go into this ticket, and which changes into #21479?

My idea is that this ticket simply allows SAGE_LOCAL to be set to a different directory and that #21479 implements the ./configure logic to automatically set SAGE_LOCAL to the --prefix given.

[mkoeppe]

OK, great. I assume that you can test #21501 separately by just setting an environment variable, so #21501 should be a prereq of #21479, correct?

[jdemeyer]

Replying to mkoeppe:

OK, great. I assume that you can test #21501 separately by just setting an environment variable, so #21501 should be a prereq of #21479, correct?

Yes.

[jdemeyer]

New commits:

​64e697d

Allow a custom $SAGE_LOCAL directory

[mkoeppe]

build/pkgs/autotools/spkg-write-makefile

@@ -45 +45 @@
 # Extract upstream autotools tarball
 cd "$SAGE_ROOT"
 PKG=autotools-`cat build/pkgs/autotools/package-version.txt`
-mkdir -p local/var/tmp/sage
-cd "$SAGE_ROOT/local/var/tmp/sage"
+mkdir -p "$SAGE_LOCAL/tmp/sage"
+cd "$SAGE_LOCAL/tmp/sage"
 tar xjf "$SAGE_ROOT/upstream/$PKG.tar.bz2"
 cd $PKG

Was dropping "var" intentional?

[jdemeyer]

Replying to mkoeppe:

Was dropping "var" intentional?

Yes, it was. This is a really temporary directory. So it should be tmp, not var/tmp.

[mkoeppe]

It seems a bit unusual, I don't think there's such a thing as a tmp directory other than /tmp or more precisely, whatever mktemp(1) provides.

But I don't insist. It's just a maintenance script for autotools, after all.

[jdemeyer]

In any case, I have installed Sage with this patch to a custom $SAGE_LOCAL directory and all doctests pass. I also tested the command line, SageNB and the Jupyter notebook.

[fbissey]

Interesting and I see Volker already merged it. Guys, I am expecting the link src/doc/common/themes/sage/static/thebe.js which is pointing to ../../../../../../local/share/thebe/thebe.js to be dangling for you. I have no solution for you, I usually deal with those at the package manager level. Although in that particular case I just added thebe.js to the source in place.

[mkoeppe]

Oh, there's a symbolic link in our sources?

[mkoeppe]

I've created #21527 for this and other cleanup issues for this patch.

[jdemeyer]

This didn't exist when this ticket was created:

$ ls src/doc/common/themes/sage/static/thebe.js
ls: cannot access src/doc/common/themes/sage/static/thebe.js: No such file or directory