Trac #34152 needs you (to vote)!

[François Bissey]

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'.
• 5 files, in config/ and m4/, total 112 KB, have been imported by using `gnulib-tool import iconv` and committed to the branch.
• Matches our practice with imported files `m4/ax_*.m4` from autoconf-archive. 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 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', but instead of using Gnulib's Programs for developing in Git checkouts, 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

[G. M.-S.]

copy files > hybrid > sage pseudo package

Thanks, François.

Guillermo

[Matthias Koeppe]

Thanks for sending out the poll, Francois.

I endorse the "hybrid" variant.

[David Joyner]

Can I give my (proxy) vote to 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+...@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.

[Travis Scrimshaw]

hybrid > sage psuedo > copy files package

I think we should be mindful that there can be people who build from source who are not developers. So not having a dependency on git is a small bonus, but I think almost everyone who has a non-Windows machine has git installed on their computer by default. I also fully agree with Dima that gnulib has no business being in Sage's git tree, and if I understand the hybrid approach, it remains separate as a separate (cloned) git repo.

Best,

Travis

[Matthias Koeppe]

On Tuesday, August 23, 2022 at 5:34:01 PM UTC-7 Travis Scrimshaw wrote:

I also fully agree with Dima that gnulib has no business being in Sage's git tree

This is a mischaracterization. None of the approaches puts "gnulib in the Sage git tree". I recommend to read the discussion on the ticket.

 

[François Bissey]

In the interest of clarity and ease of counting for me, can we keep the
thread onto votes and possibly voting issues.

Arguments should go back to the ticket or a separate thread please.

François

> --
> 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+...@googlegroups.com

> <mailto:sage-devel+...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com
> <https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Matthias Koeppe]

On Tuesday, August 23, 2022 at 5:47:04 PM UTC-7 François Bissey wrote:

In the interest of clarity and ease of counting for me, can we keep the
thread onto votes and possibly voting issues.

Arguments should go back to the ticket or a separate thread please.

 

+1

[Kwankyu Lee]

hybrid

Hearty thanks for setting up the vote.

[John H Palmieri]

hybrid > copy files > pseudo package

[Nils Bruin]

hybrid.

[it provides an immediate solution to an urgent problem *and* it provides a reasonably automated path for updating. It does indeed put some files under sage git control that shouldn't be, but compared to the urgency of the problem at the moment, that's minor.

It looks to me that avoiding the git control problem requires there to be a tarball to point at if we don't want to insist on git as a prereq for building from source. Since that tarball does not exist, we'd need to make it. We did that in the past for nearly all the spkgs. We'd basically need to have a separate repo somewhere "gnulib-for-sagemath" that maintains a tool to extract and package the required files for sagemath in an appropriate package and then host that resulting package (a tarball, I presume) somewhere. We'd just make a derivative of gnulib that DOES have tarball releases. On itself, that sounds like it could have merit, but one would weigh that against the cost. On the plus side: once the tarball is up, it would likely not change for *many* years. Only when we run into trouble would one have to pull the lever to generate a new release.

[Dima Pasechnik]

Not the whole gnulib, yet

only sage pseudo package solution does not inject parts of gnulib into Sage git tree (the other two do inject about 100K of gnulib)

 

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com.

[Dima Pasechnik]

we can of course do this, in sagemath org on github. We don't need to do anything to gnulib source.

It is very little work - just put a gnulib clone there and make a (GitHub) release.

Updating it is just refreshing the GitHub fork, and making a new Github release.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d571b46b-d973-4453-ae97-aa76c36cd676n%40googlegroups.com.

[Dima Pasechnik]

My and djoyner votes are for 

sage pseudopkg

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+...@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.

[Vincent Delecroix]

hybrid > copy files > sage pseudo package

Vincent

[Marc Culler]

If I am allowed to vote, my vote is hybrid > copy files > pseudo package.

- Marc

[François Bissey]

The vote is now closed.

Hybrid:  8 top votes

pseudo-package: 2 top votes
copy: 0 top votes

Thanks to all voters.

François