I think that this would be a major step backwards. Currently, if I make changes in one part of sage (right now: polynomials), I am sometimes a bit surprised where I am breaking code (in the case at hand: braid groups). Of course, this is rarely surprising once I look at the code, but I don't have all places on my mind all the time.
It seems to me that one of the main innovations of sage (among other CAS) was to make writing doctests really easy *and* keep them together with the code *and* make testing them *while developing* very straightforward. The final of these three points would be broken by encouraging developers to test only the parts of sage they are interested in, even if only slightly so. This can be seen in packages that were developed for sage, but not integrated, and used mostly for a relatively specific task. An example I have in mind is the ore_algebra package. Martin On Thursday 3 October 2024 at 12:30:38 UTC+2 Kwankyu Lee wrote: I can imagine this: sagemath-number-theory won't have the coding theory portion of the sage library. Hence developers for sagemath-number-theory could test their favorite distribution package quicker. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/70860fb7-ef12-42b3-a06d-d9f18ab1956cn%40googlegroups.com.
