Just ... wow. I know I don't get much of a say given my lack of recent development activity, but this level of granularity does seem absurd. It would certainly be a (psychological) barrier to development - how do you know which modules some random doctest you want to include depends on? - as well as to bug reporting - if it's optional, the first thought would be it's not really necessary to test. Travis makes some very good points.
Anyway, though I'm still not sure who is going to use sub pieces of Sage (the library), I understand that for development purposes, and for being able to add more narrow pieces (in the spirit of William's old psage, see https://github.com/fredstro/psage for the most recent activity there), it is a done deal to modularize. Kwankyu's last "block" idea seems a good compromise, particularly because it could be retrofitted to many other optional doctests for truly "optional" packages, which might actually streamline documentation for those. I also think it might be good to have a style guide telling those writing such tests to inform users/developers why a particular optional tag is needed, in a comment or something. For a lot of the optional libraries, that was fairly obvious (e.g. if you didn't have Mma or Maple installed, don't do those tests, or for the various LP solvers), but maybe that isn't so clear now. Just some thoughts. -- 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/5ea2b7cc-aa48-4113-b4d6-e585a191418fn%40googlegroups.com.
