> > It doesn't mean that the normal visible > public API of Sage changes > at all. Why do you think otherwise? >
Well, reading this thread made me think that. Because I don't see how we enforce all those "other pieces" working nicely together, so some would (perhaps quite quickly) drop by the wayside. 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!). (There's also the CRAN versus RForge etc. question...) But I don't see how this is possible with the *current* Sage. > Cars are built out of parts. Yes, parts that are, despite parts suppliers not being the same as the car companies, those parts have high tolerances and highly controlled supply chains. (Or so my brief experience with a parts supplier long ago suggests.) All your examples of "mature open source development" are not the same in their goal as Sage, which apparently aims to have all of mathematics at its fingertips (in the way that Maple and Mathematica, though presumably not Magma or Matlab, seem to). That's a lot harder to disentangle than the dozen or more R packages I've had occasion to use are, and presumably also the case in non-mathematical software. Modularity in Sage and resolving our import fiasco isn't the same thing as saying that every folder in Sage has to be a separate project, which is what you seem to be implying; though since I misunderstood the very first point, maybe I'm wrong about that too. As an example, take game_theory. This is exactly the kind of "narrow" thing one might think would survive better as a modular bit that could be imported. Which one of the programs in question it relies on (gambit) is, in terms of Python, of course. Yet there is a lot of opportunity with being inside of "real" Sage for them with interconnections with all kinds of other combinatorial and plotting and other stuff that they would be hard put to keep current without being in the Sage library. Having access to all that other math makes the game_theory stuff more powerful. I am skeptical that math can be pared down to just a few pieces that everything else fairly loosely holds fast to. But like I said, if you or ODK or someone else can make this vision happen, as long as the end user still gets the kitchen sink without having to do some wacky import yoga or use possibly-broken packages, I'm not complaining! "I also don't have a problem with things like psage or any other such packages" - and if you're right that my view on that is selection bias, I would be very happy to be wrong. (Well, not really that happy, because people have worked hard and Sage has had weird upgrades that broke their stuff. But you know what I mean.) Bring on the automated testing! :-) -- 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.
