I have recently re-written the nixpkgs sage package to use system
packages[1]
(not merged yet). While doing that I noticed that while sage patches a lot
of
its dependencies (81 out of 276 packages have a `patches` folder).
There are more or less 3 categories of patches:
1. sage-the-distribution specific patches
These patch paths, makefiles, wrappers etc. to make packages work with
other
spkgs. Thats pretty much what every distro does, too.
2. essential patches
Patches that are absolutely needed for sage to work. I consider the
python2
`re_match_index-issue_27177.patch` an example of this category, because
- it is needed for a basic sage function (regex matching)
- there is no reasonable way to work around it (`re` cannot be monkey
patched).
I'm not entirely sure why sage needs to overwrite the python integer,
but
I'm sure there is a good reason for it.
3. small fixes / opinionated patches / issues that could be worked around
within
sage
Examples for this:
- fixing a formatting failure in `backports.shutil_get_terminal_size` by
patching the spkg. That could instead be fixed by patching the sage
tests
(#25354).
- patch python to fix python bug 5755 instead of either adjusting the
doctests
or monkey-patching instead (#25316).
- patch pari to remove a warning instead of dismissing that warning within
sage or adapting the doctests (#25312)
- patch python to add path security checks (#25358)
There is no way around (1) and those patches don't really hurt anything
(except
it might be nice to clearly mark them as sage-the-distribution specific
patches). There is no way around the (2) patches and including applying
them is
usually a good idea, independent of sage.
(3) is the issue. Those patches are usually included because they fix the
problem in an easier or cleaner way than working around it within sage,
which is
reasonable. Those patches make packaging sage very hard though.
Distributions
have to either include these patches (there are good reasons to be reluctant
against new patches and you'll usually have to convince a maintainer of
their
value) or add patches to sage to work around the issue.
I would propose to make it a policy to only include sage patches when
*absolutely necessary*. If ugly workarounds or even monkey-patching is
necessary
for that, that sucks. But distributions will usually come up with even
uglier
workarounds (since they don't know the code) anyways, just resulting in
duplication of effort.
Of course I don't mean to accuse anybody that added those examples in the
past.
I understand the reasoning behind it ("cleaner" solutions). I just want to
raise
awareness about the problems this causes downstream, especially for new sage
packages (most of those issues can be forgotten once they're "solved" for
your
distribution, but the next distribution will have to solve them all over
again).
[1] https://github.com/NixOS/nixpkgs/pull/39981
--
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 post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
