#14480: switch sage to the new directory layout
-----------------------------------------+-------------------------------
Reporter: ohanar | Owner: tbd
Type: task | Status: needs_info
Priority: major | Milestone: sage-6.0
Component: distribution | Resolution:
Keywords: | Merged in:
Authors: R. Andrew Ohana | Reviewers:
Report Upstream: N/A | Work issues:
Branch: u/ohanar/build_system | Dependencies: #13015, #14781
Stopgaps: |
-----------------------------------------+-------------------------------
Comment (by tkluck):
Mind if I start making some of the (simpler) changes?
>Currently we are symlinking stuff into SAGE_LOCAL from the devel
directory (this is to make cloning fast), however this is no longer
happening in the git repository. This caused some silly breaking with the
sage-sync-build, which was in need of some heavy revision anyway. There is
now another ticket out there (don't remember which one) dedicated to
fixing + updating this script.
I couldn't find the ticket. Do you mean that your edits basically fix the
ticket? Or do you mean that the version of `sage-sync-build` in your
`build_system` branch is still in need of some heavy revision?
>> It feels wrong to me to prefer the src/bin version of the sage script
to the local/bin version. Why is this?
> I've gone back and forth on this a few times. The reason why I ended up
with this was because the latest version of the sage script will always be
at src/bin, where as the version at local/bin will only be updated if you
have rerun make.
I agree that this is the behavior, but I'm not sure whether that's what we
want. After switching branches, you could end up in the situation where
the `sage` script from one branch is using `SAGE_LOCAL` files from another
branch. Imagine that a branch adds both a package `imagemagick` and a
command `sage -convert` and it seems much more consistent to me to only
run the new sage script after `make` has been called.
But I guess that I don't mind much; whoever is in a situation where the
difference affects them, is probably doing something with the internal
workings of sage anyway, and should be able to deal with it.
--
Ticket URL: <http://trac.sagemath.org/ticket/14480#comment:14>
Sage <http://www.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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.
