One annoying thing about monorepo from a downstream perspective - but only for people crazy enough to package a development branch (OK that would be me and not many other people :) ). The split packages have their setup.py or equivalent in SAGE_ROOT/pkgs/pkg_name and some links to the single sage source tree from there. Examples: sagemath-standard, sage_setup and sage_docbuild. To package these I pull the full tree :( and then I don’t go to SAGE_ROOT/pkgs/pkg_name and build from there. If I want to patch it doesn’t work from there because patch doesn’t apply across symbolic links. So, instead I go to SAGE_ROOT/src, copy the appropriate setup.py (and any other files needed) and patch and build from there. To patch while setting the top package source tree at SAGE_ROOT/pkg/pkg_name I would have to write my own new patching machinery for Gentoo ebuilds - not gonna happen. That wouldn’t happen with split repos. For proper releases, I am hoping for separate tarballs (eventually) which means that there won’t be any issues with symbolic links.
François > On 11/10/2021, at 13:17, 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. > > 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) > - 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 > > > 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). > > 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. > > > > > > -- > 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. -- 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/7682C523-1881-4525-A55E-158FE9AE5C65%40gmail.com.
