#5852: [with patch, positive review] the detection of SAGE_ROOT in
$SAGE_ROOT/sage
script should expand symlinks recursively (fix this on systems that support
readlink -f)
----------------------+-----------------------------------------------------
Reporter: tornaria | Owner: tornaria
Type: defect | Status: closed
Priority: major | Milestone: sage-4.0
Component: misc | Resolution: fixed
Keywords: | Reviewer:
Author: | Merged:
----------------------+-----------------------------------------------------
Comment(by tornaria):
Replying to [comment:10 was]:
> It's possible that this ticket should be reverted until a major bug it
causes is fixed.
> [...]
> For the record, this is *not* how I meant the sage script is meant to be
used. I bet this isn't documented, but it should be. The script should
never be used that way. Instead one should do
> {{{
> /home/sage$ cp /home/sage/sage-3.4-symlink/sage /home/tornaria/bin/sage
> }}}
> and then edit the copied script to explicitly point to the ROOT. It
was never my intention for somebody to run the sage script unmodified
outside of SAGE_ROOT. Me not intending this means that elsewhere in the
Sage build/test system this assumption is made, and the workaround on this
ticket actually seriously breaks things for some users.
If you only use the script in *that* way, then the
{{{
if [ "$SAGE_ROOT" = "....." ]; then
}}}
branch would never be taken, and as the patch in this ticket only touches
this branch, it can't break anything.
In practice, it is much more convenient to just use a symlink to the
script, if it can be worked out. Before this patch, it turned out that the
real, canonical path for SAGE_ROOT could be identified incorrectly, and
*this* causes doctesting to fail.
> The change in this ticket causes serious breakage for people whose home
directory is NFS mounted, and for which their Sage build is on another
volume that is symlinked from their home directory. i.e., this sort of
setup:
> {{{
> cd ~wstein # my home directory is NFS mounted.
> mkdir /tmp/wstein # /tmp is a local disk
> ln -s /tmp/wstein sage-build
> cd sage-build #
> # build sage here, doctesting fails completely
> }}}
>
> I'm doing a test build for myself to confirm that this happens, and if
so and I can't figure out how to fix this promptly (maybe I will be able
to), then we have to revert this change, and document that one can't just
symlink the sage script out.
This sort of setup is *exactly* what used to cause breakage for me,
because the {{{SAGE_ROOT}}} was incorrectly computed (to a non-canonical
path). What would you expect {{{SAGE_ROOT}}} to be computed to, other than
the canonical path? e.g., continuing your example above:
{{{
cd ~wstein/sage-build
tar xvf sage-nnn.tar
cd sage-nnn
./sage -sh
echo "$SAGE_ROOT"
}}}
Are you expecting SAGE_ROOT above to be "/home/wstein/sage-build/sage-
nnn/", or "/tmp/wstein/sage-nnn" ?
Before the patch, it was the former, non canonical path; after the patch,
it is the latter, which is IMO the correct canonical path. When SAGE_ROOT
is non-canonical, running doctests for files in the sage library fails b/c
they are not recognized as part of the sage library, etc.
I don't see how the fact that this is NFS mounted could be relevant to the
issue.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5852#comment:11>
Sage <http://sagemath.org/>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
