On Friday, April 15, 2016 at 5:12:28 PM UTC+1, vdelecroix wrote: > > I don't think that the question where to cut is meaningful in a first > time. Cutting more should not be a problem. > > I would make an important distinction between: > > 1 - Core fonctionality that we may package in some way to be useful to > others. I think Cython, cysignals are meaningful examples. Though, these > two examples are developed outside of Sage. > > 2 - Optional functionality that may be useful to Sage users. > > This is basically the distinction we currently have between a "Sage > core" (still made of packages) and "Sage optional packages". Of course > there could be much more that currently in both categories. >
IMHO you are underestimate how well-connected Sage lib is. > > Examples of possible cutting of type 1 (Sage core): > > - a lot in sage/libs (e.g. pari and the work of Jeroen to update > cypari [1], the gsl interface, interface to LP solvers, ...) > LP solvers are used by graphs, coding theory, what else? > - fast_callable as Erik mentioned > > perhaps. > Examples of possible cutting of type 2 (things that needs Sage core): > > - graphs > - a large part of combinat > graphs are used by combinat (posets!), and graphs use combinat. Posets are used by polyhedral code, which is also used by combinat, and by various toric varieties stuff... - games > - modular groups > - elliptic curves > perhaps. > > I think that the development framework should not necessarily be the > same for both. I feel like we should keep "Sage core" as centralized as > possible concerning its development. Even though, each release of Sage > might also be a release of other subpackages. > > Concerning the extras, I think that it should not be a problem to make > it very open. On one hand, some of them could still be centralized in > development with Sage core. But anybody should be able to have its own > package on its webpage as it already exists. > > Hence for me we lack in order: > > * a model that allows centralized development but modularized > distribution > > * a patchbot that tests core and optional packages as well as their > interactions > > * a nice howto (as already started by Chris) > > * having a centralized way of testing for presence of extra packages > (a good step would be [#20382]) > > Starting cutting is just about people time and interest... > > Cheers > Vincent > > [1] https://github.com/jdemeyer/cypari > [#20382] http://trac.sagemath.org/ticket/20382 > -- You received this message because you are subscribed to the Google Groups "sage-devel" 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
