Le vendredi 09 mars, Keshav Kini a écrit:
> - leave SPKG repos where they are for now
Big sigh.
I missed that line.
Even bigger sigh.
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubs
On 2012-03-09 06:18, Keshav Kini wrote:
> Does this sound feasible?
You would probably need to change a lot of hard-coded directories. So,
lots of boring work but it could be done.
> Something else: Why do we even have local/ ? Why not just have bin/,
> lib/, etc. in the root directory?
I like lo
I would leave data/extcode alone for now. If you want to do something
something with it, it should be part of "refactoring $SAGE_ROOT/data".
I don't think extcode should be special-cased among the subdirectories
of $SAGE_ROOT/data.
--
To post to this group, send an email to sage-devel@googlegrou
On 2012-03-09 09:29, Jeroen Demeyer wrote:
> On 2012-03-09 06:18, Keshav Kini wrote:
>> - Make `sage -b` also run `sage --python devel/sagenb/setup.py develop`,
>> copy relevant files from devel/sagebin to local/bin/ , and copy
>> relevant files from devel/sageext/ to... somewhere, perhaps shar
On 2012-03-09 06:18, Keshav Kini wrote:
> - Make `sage -b` also run `sage --python devel/sagenb/setup.py develop`,
> copy relevant files from devel/sagebin to local/bin/ , and copy
> relevant files from devel/sageext/ to... somewhere, perhaps share/sage/ ?
Thereby complicating the development p
On 2012-03-09 09:18, Julien Puydt wrote:
> Le vendredi 09 mars, Jeroen Demeyer a écrit:
>> You forget to address one very important point: *why* should we do
>> this? Which problem will it solve?
>
> The problem of having a hundred of packages each its own repository,
> its own history, with no si
Le vendredi 09 mars, Jeroen Demeyer a écrit:
> You forget to address one very important point: *why* should we do
> this? Which problem will it solve?
The problem of having a hundred of packages each its own repository,
its own history, with no simple way to get overviews?
Snark on #sagemath
--
You forget to address one very important point: *why* should we do this?
Which problem will it solve?
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this grou
Hello,
There has been a lot of talk recently about totally refactoring the way
that a Sage installation is structured, which is great, but will no
doubt take a lot of effort.
Looking at the directory structure of lmonade (and talking to Burcin on
this list about it a bit), as well as `R. Andrew O
