I strongly disagree with your conclusion that this is a bug, much less a severe one. My understanding of William's goal (please correct me if I am wrong) was to put everything together so nobody was trying to build a better wheel. To me, by splitting everything up into these small pieces, it seems contrary to that goal as how is someone suppose to know the piece they want already exists? For instance, the backend libraries all have existed on their own, and they aren't going to change.
What you seem to be proposing is a large maintenance burden as we have to 1) Write code that keeps the modularization both "upstream" and "downstream" within Sage's ecosystem. 1b) Write code in nonstandard ways to break certain dependencies that are there in practice. 2) Write doctests with tags (at various levels, e.g., individual, block, module) that will need to be updated. 2) Test the code with all of the different dependencies so we don't break (1) and (2). My reading is that your main goal is to make Sage pip-installable, but that seems independent of breaking Sage up into smaller parts. Even breaking up Sage into smaller portions for more 'precise' dependencies for these supposed downstream Python developers won't really fix B and C. I agree with Dima that splitting off some of the smaller pieces into pip-installable projects that Sage then depends on is a good thing to do, but I think this is better down with a bottom-up approach by taking it away piece by piece. I also would like to see an increase in the number of developers and users. Yet, we are still primarily math software with an eye towards research, which means we will always have a somewhat limited developer base. I am hoping you could answer the following questions in detail with your next post. I) How do you expect the amount of work the average developer will have to put in to add a new component (e.g., a Python module on a new linear optimization routine) to Sage? To fix a small bug? A larger bug (say, requiring changing 3 or 5 files)? II) Related to (I), but what automated tools do you expect to produce and when will they be available? What extend will they reduce the developer overhead? How accessible with their output be to read? III) How do you expect this to bring new developers in? Do you have any evidence (including anecdotal) that this would increase the number of developers? (Since switching to GH, I have not noticed much of a change in the number of developers or the amount of contributions. I recall this being one of the claimed benefits to the switch. This feels like it should have had a larger impact than the proposed modularization.) Why would these larger-Python-ecosystem developers even contribute their code to Sage rather than just do their own off-shoot/one-off projects (that we wouldn't know about)? IV) How would a user know what components are out there? Why don't we need to first have a better package-manager/distribution-platform/etc. first (which includes all of the downstream Sage pip-packages) before we try to split Sage up? I would expect this to be a requirement for modularization. Or are you still expecting people just to install one "Sage" thing and never have to worry about anything else? V) How are we going to make sure code doesn't bitrot? In particular, who is responsible for fixing code that breaks "downstream"? Right now, that is clearly the work of the author(s), but could the following situation happen? Suppose we have a base Sage module A, then Bob writes his own separate library B that depends on A that we then include as part of the main "Sage" distribution. I make a change to A that breaks B. Who should fix it? What if Bob is no longer maintaining B? There are many things I would like to see with your proposal included into Sage, and thank you for undertaking such a huge project. I have some reservations about the benefits over the costs, and I think it would be beneficial to have a more detailed plan before proceeding further. Best, Travis On Friday, June 9, 2023 at 4:48:15 PM UTC+9 Matthias Koeppe wrote: > On Friday, June 9, 2023 at 12:40:52 AM UTC-7 Dima Pasechnik wrote: > > some other examples of such pip-installable spin-offs of parts of > Sage, some with binary wheels, some without, are pplpy, cysignals, > primecountpy > (more of this should come) > > > Yes! Making sure that all of these have (automatically built) binary > wheels would be very important work. > > > At some point we should consider fully switching to gmpy2 to provide > interfaces for gmp, mpfr, etc. > > > Indeed. This idea is tracked in > https://github.com/sagemath/sage/issues/35559 and if this can be done > without sacrificing performance, this would be a welcome simplification. > > > -- 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/26f1e786-e3e4-4d1a-99fd-3fe25ba05262n%40googlegroups.com.
