On Tue, Apr 5, 2016 at 8:44 PM, William Stein <wst...@gmail.com> wrote: > Some thoughts: > > - For now, work can be done that is valuable but doesn't have to > impact the current sage/trac workflow. For example, somebody might > create an awesome Python package that does BLAH and depends on the > core Sage library (what you get via "import sage" now).
FWIW in the Astropy project we have a concept called affiliated packages [1]. The idea behind this is that if someone says "Hey, I need <relatively specialized> functionality for my work, can you add that to Astropy?" And we say, "No, because none of the Astropy core developers understand this subject well enough to maintain the code, and it's perhaps a little too specialized. But you could implement it as an affiliated package." We require for affiliated packages that they depend on Astropy and use Astropy's core features, such as common data structures, file format handling, time and coordinate transformations, etc. etc. This ensures that all affiliated packages interoperate well with each other through the core Astropy features (in analogy to sage these might be common representations of various core mathematical objects). The benefits of being an "astropy affiliated package", in addition to promising a certain level of interface commonality as described above, also include being advertised through Astropy. We're also working on the ability to better discover the functionality provided by different affiliated packages such as a cross-documentation search. That's still an open issue though. And sometimes affiliated packages may be merged into the Astropy core package as well. This has't been done often yet, but it has been done and will be done again. For example the "gwcs" package is intended to be an Astropy core package, but it's still very experimental and volatile so it's better to develop it as a separate project for now, rather that merge it directly into the Astropy core and then be left being basically unable to make stable releases until the "gwcs" feature is ready (or being forced to make releases with big warning flags around incomplete features). I thinks a model similar to this could work well for sage, and also free its core developers from having to maintain huge piles of already poorly-supported code (some "affiliated package" projects die out, but it has no impact on the Astropy core). Erik [1] http://www.astropy.org/affiliated/ -- 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.
