On Monday, 11 October 2021 at 09:36:54 UTC-7 Matthias Koeppe wrote: > On Monday, October 11, 2021 at 1:31:14 AM UTC-7 Dima Pasechnik wrote: > >> >> I believe that this hinges on reliance of Trac a lot, but we should not >> be bound by it. >> With Trac gone, most benefits of monorepo will go, as well. >> > > Not at all. Still the same even with a switch to using GitHub. > > I *really* appreciate that I can install sage from source and have it ready for development by issuing a single git clone (well, a second one to get git-trac. That's a bit annoying) and then a combination of make and configure that I can never remember, but the system helps me along. I find it a little annoying that it recommends a "yum install..." of a whole bunch of stuff, where that really should be a "dnf install ...", but that's again an easy edit to make.
I also really appreciate that fixing something and/or stepping between different branches is all done through a single git repo, so that "git branch ..." gets my entire relevant tree in a sensible state (and I don't have to figure out where to submit fixes in different parts of the tree). I absolutely dread having to navigate multiple git repositories for making a fix and/or having to figure out WHICH repository a fix should go into. Currently, having code spun off in "spkgs" is already a barrier to fixing things. Recently there was a ticket where some maxima/ecl patch needed work. The only reason I was able to contribute there was that the whole situation could be recreated by monkey-patching maxima on the spot. Figuring out how to pull/patch/build an spkg would have been a prohibitive barrier. I understand the rationale behind the spkgs, but I would think splitting up sagemath in more repositories would pose a higher barrier of entry to contributions. So PLEASE make it possible to pretend sagemath is still in one big repo, where the same build tools all apply. Another worry that I have is that modularizing sage will lead to destabilization. The original reason for putting all components of sagemath into one big environment was to reduce the number of variables in getting things to work. I expect that if modularization takes off and sage ends up split in more components, then 10 years down the road there will be a group of developers that throw their hands up in desperation because it's just so hard to get all different components together with versions that actually work well together, and trying to keep different components working across version ranges is just so tricky (plus it's too hard to get exactly the right versions from all places, because the newest version of some components will always just have made some incompatible change that the others still have to catch up to). So PLEASE make it easy to have a reference of known-to-work components together, like sage-the-distribution does. I think we'll need it in the future again. -- 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/866ac025-586e-4836-b09c-a59e834f3a07n%40googlegroups.com.
