On Tue, Apr 12, 2016 at 9:58 PM, William Stein <wst...@gmail.com> wrote: > On Tue, Apr 12, 2016 at 12:50 PM, kcrisman <kcris...@gmail.com> wrote: >> You are right, as I apparently >> didn't make clear, that it would be even better to have people more easily >> able to have separate packages that are quite narrow - and I think that a >> testing framework like R has would probably suffice for this (as long as >> breaking such packages was a blocker for release!). > > It may or may not be, depending on the package and why it broke. > That's up to us to decide.
Sorry to keep bringing up Astropy here--it by no means does everything perfectly--but it is a good analog to Sage in many ways due to general similarities between scientific software communities. Anyways one thing that Astropy provides for Affiliated Packages is a "package template" [1] that allows all Affiliated Packages to be built and packaged more or less the same way. They aren't *required* to use the package template, but the vast majority do because it's convenient--it sets them up with the same testing and documentation tools that the Astropy core package uses it. And even more importantly (and the reason I bring this up) is that it includes templates for configuring their package to be built and tested on continuous integration platforms like Travis [2] and AppVeyor [3]. The default templates include Astropy as a build/test dependency, and include separate build job configurations for using both the latest stable release as well as the latest version from git. This means that affiliated package authors typically find out quickly if a change in Astropy breaks their code too. This doesn't happen that often due to the slow deprecation process, but it does happen (probably most commonly if some import changes). We can then work with the maintainers of the individual affiliated packages to resolve the issue--whether it's putting the right astropy-version-specific code in their package, or backing out changes or providing better backward-compatibility in Astropy. Unit testing and continuous integration really make this a mostly painless process, and by providing package authors with the tools to do these things easily we promote best practices. Best, Erik [1] https://github.com/astropy/package-template [2] https://travis-ci.org/ [3] https://www.appveyor.com/ -- 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.
