My and djoyner votes are for sage pseudopkg Dima
On Wed, 24 Aug 2022, 00:38 François Bissey, <frp.bis...@gmail.com> wrote: > Hi all, > > https://trac.sagemath.org/ticket/34152 needs help to decide what solution > we implement going forward. > > The ticket is concerned with updating the bootstrap process by removing > the current need for gettext and replacing it with gnulib ( > https://www.gnu.org/software/gnulib). gnulib is not a regular software > library but a collection of bits and pieces to help portability across > platforms. > > The issue at hand is how do we include and use gnulib in sagemath. > Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and > across most of the ~250 comments of the ticket about the way to proceed. At > some point it became clear that they would not agree and would need > arbitration. This is what this post is about, I am inviting the sagemath > community to weigh in and decide the issue. > > The ticket summary has been updated with summaries of the problem and of > both options along with links to branches implementing them. I would not > recommend diving in the comment section. > > There are 3 (three) options to choose from, one from Matthias, one from > Dima and a hybrid approach they tried to create. > > -- copy files -- > > - Follows approach 3 of the Gnulib manual section 'Integration with > Version Control Systems' > <https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html>. > - 5 files, in config/ and m4/, total 112 KB, have been imported by > using `gnulib-tool import iconv` > <https://www.gnu.org/software/gnulib/manual/html_node/Initial-import.html> > and > committed to the branch. > - Matches our practice with imported files `m4/ax_*.m4` > <https://github.com/sagemath/sage/tree/develop/m4> from > autoconf-archive > <https://www.gnu.org/software/autoconf-archive/The-Macros.html>. > Different from our practice with SPKGs because the files are needed to > generate the configure script. > - Introduces no new dependency. > - Burden on a developer who authors an update ticket for these files: > Obtain gnulib by cloning the repo, then re-run gnulib-tool import, > remove unneeded files (that's where #29549 > <https://trac.sagemath.org/ticket/29549> went wrong), commit the > changes. (Updates are expected to be necessary only very rarely.) > - Burden on users and other developers: None. > - dimpase's criticism of this approach: "gnulib's code is not Sage's > code, it has no place in Sage git tree; this way, updating the imported > gnulib files is tricky and error-prone by design". > > -- sage pseudo package -- > > - Follows approach 2(C) of the Gnulib manual section 'Integration with > Version Control Systems' > <https://www.gnu.org/software/gnulib/manual/html_node/VCS-Issues.html>, > but instead of using Gnulib's Programs for developing in Git checkouts > > <https://www.gnu.org/software/gnulib/manual/html_node/Developer-tools.html>, > implements its own script (making checkout much faster, as full gnulib > checkout > is 250 MB). > - Introduces a new (although one can't really do Sage development > without git installed) dependency on git and on availability of > internet connection at the first run of ./bootstrap in a tree, to pull > 83 MB (fair to say that internet is needed for Sage development a lot, > anyway). > - Burden on a developer who authors an update ticket for these files: > Edit the bootstrap file to change the commit hash, verify that the > list of files removed by make bootstrap-clean is still correct, commit > this change > - Burden on other users: a pseudo-package needs to be installed once > (and updated, automatically) > - mkoeppe's criticism of this approach: "Having bootstrap operate a > multi-megabyte git clone (on the 1st install and when there's a change of > the gnulib commit hash) in the upstream/ directory increases > complexity for no benefit." > > -- hybrid -- > > - Resolves the criticism on the "copy files" approach: "updating the > imported gnulib files" is now assisted by the spkg-src script (adapted > from dimpase's branch) > - Resolves the criticism on the "Sage pseudo-package" approach: > "operate a multi-megabyte git clone (on the 1st install and when there's a > change of the gnulib commit hash)" is only done by authors of tickets that > update gnulib, not by general users of bootstrap. > > Vote is open now and will close - tentatively - on the 29th of August at > 12pm New Zealand time [my time zone] when I will do the tally. If no option > gets a majority, the voting period may be extended by a few days. > Please vote! > [ ] copy files > [ ] sage pseudo package > [ ] hybrid > > > -- > 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/CAP1Dv6a4xp5a1y-idOms4yHKCG1sv%2BzO771rQ0MUxrmAfL%2BLRQ%40mail.gmail.com > <https://groups.google.com/d/msgid/sage-devel/CAP1Dv6a4xp5a1y-idOms4yHKCG1sv%2BzO771rQ0MUxrmAfL%2BLRQ%40mail.gmail.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/CAAWYfq3ymL6cRm6RB%3DvTcuiWkNQS5JruyDXoWhiXYGqT6fOOqw%40mail.gmail.com.
