On Thu, Apr 14, 2016 at 3:21 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> wrote: > A really important point (which so far hasn't been addressed) is how to deal > with breakages of affiliated packages. I see two ways:
These are good questions. > 1. If I make a change to some core package, it is my responsibility to > ensure that no affiliated package breaks. > > 2. It is the responsibility of the affiliated package to fix breakages. Those are the most obvious but there are other ways. A variant on #2 is that it's the responsibility of the affiliated package's maintainer to perform integration testing of their package and report issues that result from upstream changes. But whose responsibility it is to "fix breakages" may depend on the particular issue. I agree with the overall premise though. > I think both of the above have problems: > > With 1, the author of the core package might not have access to the > affiliated package: how do you force your affiliated package to accept a > needed change? This is the current situation with Sage and SageNB. > > With 2, breakages will need to fixed after the fact (after the change to the > core package has been merged already), leading to occasional breakages for > end users. This is the current situation with Sage optional packages. I agree, mostly. Both of these *are* problems. Astropy doesn't do #1--that is, there is nothing that tests Astropy core changes against all affiliated packages (rather, the affiliated packages run their own tests against the latest Astropy core--the inverse). I think there has been some discussion of adding affiliated package tests to Astropy's main contiguous integration matrix and I think that would be a good idea. It would also enable better integration testing between affiliated packages (some already do this--for example APLpy [1] depends on WCSAxes [2]--both are Astropy affiliated packages and use (different) functionality from the Astropy core library. Implementing #1 would seem to require addressing problem #1. However, this needs to be addressed either way--if some changes are made in the core package that break affiliated packages then the affiliated package *may* have to be updated regardless of how the breakage was discovered. If truly nobody can maintain an affiliated package anymore it might die. And that's a problem since it might mean loss of functionality for users, but it's a less bad problem then having unmaintained code sloshing around in the main package (and if a package goes unmaintained it probably didn't have many, if any users beyond its original author anyways). It should be pinned to require the last versions of its dependencies that it did work with so that it can be easily installed in a virtualenv if absolutely needed, and then be sent out to pasture. Problem #2 does result specifically from requiring affiliated packages to do their own integration testing. That's why having more integration testing for the core package would be good too. This is rarely a huge showstopper though. These issues are almost always caught in development and don't affect anyone but the affiliated package author, and usually not for long, as their package will normally still work with the latest stable version. In *some* cases the development versions of an affiliated package will depend on the development version of the core package, but in most of those cases the affiliated package author is working closely with whoever is working on the dependent features in the core package (or often are the same person(s)). Finally, in the rare cases where a release gets out that breaks integration it can be addressed quickly by a patch release. Currently Sage doesn't do patch releases, but it should. Especially if there is a move toward increased modularization. But that's more a separate issue. Erik [1] https://aplpy.github.io/ [2] http://wcsaxes.readthedocs.org/en/latest/ -- 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.
