This has been a very interesting discussion... There are pros and cons to modularity, and it's worth noting that this can be done at various different levels. For example, where I work we have a single, monolithic codebase (very convenient) but at the same time have fairly strict, explicit dependencies, public APIs, and owners (modular).
As for which direction Sage should move, more below... On Wed, Apr 20, 2016 at 2:25 AM, Erik Bray <erik.m.b...@gmail.com> wrote: > On Fri, Apr 15, 2016 at 8:04 PM, mmarco <mma...@unizar.es> wrote: > > My proposal would go in the direction of having three categories: > optional, > > experimental, and external. Optional and Experimental would follow > moreless > > what we have now, external programs that provide some functionality, and > we > > keep them in our packaging system because we cannot rely on them being > > provided by the distro (or maybe we could, but we need some patching or > > specific version). They are more tied to "Sage the distribution" than to > > "Sage the library". > > > > What I propose to call external packages would be something different. > They > > would go in the spirit of sage/python code writen by sage users for their > > teaching/rsearch/whatever. In that sense, they would be in spirit closer > to > > "Sage the library", but the Sage development team would make no promises > > about it (since it wouldn't go through the review process). They could be > > provided by any of the usual ways to install python modules (pip, > > easy_install...) but we could have some kind of database to do some > > automatic testing. We could even distribute them (as optional packages or > > calling them dfifferently). I think providing a template and howto for > the > > people that wants to share this kind of code is a good start. A next step > > would be to maintain a database and maybe include some automated way to > > install them. > > +1 I think this is in the right direction. And I think that some of > the existing leaf packages of the core sage-lib could be > re-distributed in this form. But as Vincent has repeatedly written it > would be more important to have this infrastructure and process in > place than it is in most cases to decide specific things to *remove* > from sage-lib. Even though I think there are things that should be > split out I could agree it's not as urgent to do so, and it should be > handled with great care. > +1 We should build the infrastructure to make it easy for packages to depend on Sage but not be part of Sage. Part of this is a cultural shift. But I think tooling could be a huge part of the process. One thing people forget is that CPU cycles are actually pretty cheap. (Initially I didn't know how up-to-date the patchbot would be, but was pleasantly surprised that, with the exception of right after a new release, a single machine was able to keep up and was still idle most of the time.) Simply making it easy for a project to run it's tests against every commit (or even pull request aka trac ticket) of Sage, as well as the latest release, could go a long way. We wouldn't promise to not break external packages, but at least we couldn't do so in ignorance which is 90% of the battle. Once this is healthy, we can think about moving existing, loosely-coupled, less-frequently-used modules out. Well defined dependencies and public APIs within "core" Sage would be a useful cleanup too... but that's another story. - Robert -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
