On Mon, Oct 11, 2021 at 1:17 AM Matthias Koeppe <matthiaskoe...@gmail.com> wrote:
> As we are making progress on preparing the Sage library for modularization > (https://trac.sagemath.org/ticket/29705), here's a discussion of three > things that need to be decided whenever a portion of the Sage library is > modularized: > > *(1) Namespace:* Will it be imported as (+) "from > sage.hermeneutics.quantum import QuantumGravity" or (-) "from > transformative_hermeneutics.quantum import QuantumGravity"? > > *(2)* *Distribution name (= project name):* Will it be installed using > "pip install transformative-hermeneutics" or "pip install > sagemath-hermeneutics"? > > *(3) Source repository:* Is the source maintained as part of the Sage > repository using Trac tickets (MONOREPO); or in a separate repository on > GitHub, GitLab, ... (MULTIREPO)? > > This post is dedicated to the MONOREPO vs. MULTIREPO question, and how it > relates to (1) and (2). > > *Some details about MONOREPO:* > The Sage repository already contains several separate distribution source > trees. Since Sage 9.4 they are located in the subdirectory SAGE_ROOT/pkgs > (see > https://wiki.sagemath.org/ReleaseTours/sage-9.4#New_location_for_distribution_package_sources:_SAGE_ROOT.2Fpkgs > ). > For example, SAGE_ROOT/pkgs/*sage-sws2rst* is a self-contained source > tree of this distribution package: It has standard Python packaging files > such as setup.py. > SAGE_ROOT/pkgs/*sagemath-standard* is also a source tree of this > distribution package; but it is created in part using symbolic links into > SAGE_ROOT/src. This is the trick that has allowed the modularization effort > to *keep the SAGE_ROOT/src tree monolithic: *Modularization has been > happening behind the scenes and will not change where Sage developers find > the source files. > > *In favor of MONOREPO:* > + The Sage developer community is used to using Trac > + The process is well defined: No code "ownership" (all Sage developers > can change any code, subject to peer review); changes are synchronized > + There is implicit integration testing with all of Sage > > *Drawbacks of MONOREPO:* > - Extra hurdle for attracting new developers from outside the Sage > developer community (everyone who is not already a Sage developer uses > GitHub or similar) > - Testing infrastructure needs to be set up and maintained separately; in > particular, integration testing with Sage. > you put aside the very fact that dependence on Trac is a problem in itself - it's a crumbling monster that eats in our money and time. Just yesterday I spent nontrivial amount of time sorting out why certain notification emails are not arriving - it turns out they are not even sent out by Trac, for the reason unknown, and probably never to be known. This is very far from ideal, and getting worse - we were in the past years helped by Erik, who knows a lot about Trac, but this is no longer the case. > *Evidence:* > - The pynac situation -- now finally resolved by merging it into the Sage > library ( > https://wiki.sagemath.org/ReleaseTours/sage-9.5#Modularization_and_packaging_changes > ) > merging pynac into Sage tree has not resolved the bigger problem - that pynac is buggy, that we don't have developers who know the pynac code, no docs exist explaining the differences, that pynac code is too far from ginac to be re-merged, and that we should be getting rid of it for. - Even for separate git repositories hosted in the SageMath GitHub > organization (https://github.com/sagemath/), code ownership and review > workflow are unclear. > - For example, https://github.com/sagemath/sage-numerical-backends-coin > provides no information on how to contribute (commonly expected in a file > CONTRIBUTING.md) > - Neither does https://github.com/sagemath/cysignals, which moreover > looks abandoned: Issues and PRs are not tended to. Is it subject to peer > review like other parts of Sage? Who is in charge of merging PRs? > - Similar issues with https://github.com/sagemath/cypari2 > these issues are primarily due to the primary developing spot being Trac, being disconnected from Sage's GitHub and this disconnect necks participation of Sage developers in these GitHub-based sub-projects. > > *Recommendation:* Keep MONOREPO for all distributions that fill the > sage.PAC.KAGE.MODULE namespace (= distribution packages named *sagemath-... > *-- according to my recommendation in part I). > 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. > *Recommendation: *For distributions that do not use the > sage.PAC.KAGE.MODULE namespace (= distribution packages named something > other than sagemath-... -- according to my recommendation in part I), weigh > the benefits vs. drawbacks of MONOREPO vs. MULTIREPO. It is also simple > enough for a distribution to start out being developed inside of the Sage > MONOREPO and to be split out to a separate repository later. > > *Recommendation:* Discuss the development workflow for projects in the > https://github.com/sagemath organization, and document it in files > CONTRIBUTING.md in the individual repositories. > My recommendation is to start switching to GitHub (or GitLab) now. This will diminish our over-reliance on Trac, it will lower the entry barrier into the project, it will naturally facilitate modularization, improve testing, etc etc. Another recommendation is to look for yet another splitting possibilities - at Git submodules. E.g. SciPy has half a dozen Git submodules. To this end, I'm stopping doing any non-real-emergency stuff related to Trac (and its git server, which is a separate pain in the neck) maintainance/updates, now (I'm willing to work on exporting Trac to GitHub, etc). Dima > > -- > 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/1572d163-abba-4fde-b348-5f31166d4b87n%40googlegroups.com > <https://groups.google.com/d/msgid/sage-devel/1572d163-abba-4fde-b348-5f31166d4b87n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAAWYfq0tO2%2BKmWn-_4VSnB9OAmRHXqbkstLomLZEJjCVxJ0L_A%40mail.gmail.com.