On Tue, Jan 15, 2013 at 8:01 AM, Burcin Erocal <bur...@erocal.org> wrote:
> On Tue, 15 Jan 2013 10:27:38 -0500 > Jordi Gutiérrez Hermoso <jord...@octave.org> wrote: > > > Actually, I don't see what ditching hg has anything to do with the > > real meat of the actual problem, fixing the build system. > > +1000 > > I don't recall the design of the new "development model", "directory > structure" or "build system" being discussed anywhere public. From > references on the mailing lists, I understand that there were > discussions during various Sage days. But shouldn't there be a thread > on sage-devel where people can give feedback before we go through with > these changes? > > > Keshav, Jordi and many others have pointed these out before, but > our main problem seems to be: > > - we are not really using a DVCS > - the build system is showing its limits due to the rapid growth of > Sage > > I don't think "switching to GIT" will solve either of these problems > directly. Why don't we discuss the solutions to these problems > separately and put them into action? > FYI, the whole switching to git is only looking at addressing the development model, not the build system -- but as switching to git gives us a chance to re-examine the directory structure, and modify it, the (current) build system will necessarily have to be modified. > > - Development model: > > I like the idea of keeping a branch for each issue on Trac. I have > even suggested using mercurial's pbrach extension for this > purpose privately to William about 2 years ago. > > With a student, I even set up a patched roundup install with this > feature. I can enable it on the lmonade issue tracker if anybody is > interested in testing this out. Though I believe using gitlab and > not reinventing the wheel is far better. > Please see http://wiki.sagemath.org/WorkflowSEP for a description of the issues, and a work in progress of the proposal. > > - Build system > > This actually has two items: > > - integrating the repositories > > Why? > > AFAICT, the only reason is to allow us to specify the dependencies > of the Sage library better. ATM, when a patch goes into Sage, the > corresponding patch to update the spkg is in a separate > repository. Putting these together would help coordinate the two. > > Do we really need to coordinate these? Why is Sage any different > from any other large software package out there? > > The standard solution to this problem is to add a "configure" > script to the library which checks if the dependencies are > satisfied and sets various options for the compilation process > accordingly. > > The initial design of Sage separated the mathematics library from > the distribution system, then further separated the user interface > (notebook) from the mathematics library. Why are we now trying to > reconcile a bunch of shell scripts with a Python/Cython library > for mathematics? I don't inherently disagree with you, but I don't necessarily see a path to getting to that point, as sage's library is so fixated on being part of the sage distribution at the moment. Maybe you have thoughts? > > - rewriting the build system > > I agree that things can be done much better, but I don't > understand why there is talk of rewriting. There are plenty of > excellent package managers around. Why not just use one of > them? > I have probably overused the word "rewriting", when probably I should have been using "replacing". That said, I'm not at convinced that switching to portage (the commonly proposed replacement) is a good decision. Portage is huge, monolithic, and (from my personal experience) relatively slow -- sage doesn't need something so complicated, and its monolithicity makes modifying it (when necessary) a relatively painful process. Also, portage was not initially designed for prefixed environments, but rather had that functionality added in later, and so it doesn't always behave the best in such use cases. I would rather see sage use a lightweight, relatively minimally featured package manager that was designed from the ground up for prefixed environments, however, I am not aware of any package manager around that satisfies such criterion. > Cheers, > Burcin > > -- > You received this message because you are subscribed to the Google Groups > "sage-git" group. > To unsubscribe from this group, send email to > sage-git+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Andrew -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
