Adding functionality that depends on upgrading a standard package.

[mmarco]

I recently released a new version of libbraiding that exposes new functionality, in order to use those new functions from Sage (see #38887).

However, the CI tests fail because they use the old version (taken from the system, instead of installing the new spkg).

Which is the right way to proceed in this case? Should I somehow force the containers to build the new spkg?

Best,

Miguel

[Michael Orlitzky]

Ideally sage would support both old and new versions at the same time,
so that not everyone has to upgrade at the same instant. Of course
this is not always possible and/or can be a huge waste of time.

You can force the sage distribution to build a local copy of
libbraiding by changing its spkg-configure.m4 to detect some feature
that is only present in the new version of libbraiding. That will fix
the sage-distro CI runners, but most linux distros, and now the meson
CI, won't be using the sage distribution at all. There may be some
unfixable breakage in that case if you are e.g. waiting for conda to
update libbraiding and conda is waiting for sage.

That same conda-esque breakage will happen elsewhere too and will
require everyone to quickly update libbraiding and patch their sage
packages which is why it's best avoided if it's not too hard.

[Nils Bruin]

Would this be caught by changing the version requirement? Then the old version provided by the system wouldn't satisfy sage's version requirement any more, so wouldn't that push sage to install its own?

[mmarco]

How do I fix a version requirement?

[Nils Bruin]

This response is more a test case in how easy it is for a sage packaging novice (me) to figure out what to do, so take this with some scepticism and some advice from experts: I did find this one:

https://doc.sagemath.org/html/en/reference/spkg/libbraiding.html

There is obviously the "package version", but as I now see, the "equivalent system packages" don't seem to encode an explicit version restriction at all. So I guess Michael's comment on spkg-configure.m4 is probably appropriate. I guess explicit testing for exactly what you need there would be the most flexible, but the requirement there could also just be a check on the installed version number, I guess. In that case, sage installation should detect whatever system-installed libbraiding there is, run its test (look up the version number and compare it with the value) and then decide if that's good enough.

I would think it's philosophical debate on what kind of test is preferred: rather strict testing on version numbers would restrict you to more restricted but known-good configurations, whereas feature testing would be more permissive but risk to accept a version that ends up looking superficially as functional but not actually a tested-good version.

[Michael Orlitzky]

On 2024-11-01 04:32:35, Nils Bruin wrote:
> There is obviously the "package version", but as I now see, the "equivalent
> system packages" don't seem to encode an explicit version restriction at
> all. So I guess Michael's comment on spkg-configure.m4 is probably
> appropriate. I guess explicit testing for exactly what you need there would
> be the most flexible, but the requirement there could also just be a check
> on the installed version number, I guess. In that case, sage installation
> should detect whatever system-installed libbraiding there is, run its test
> (look up the version number and compare it with the value) and then decide
> if that's good enough.

In general, and with libbraiding, there's no easy way to tell the
exact version number of a package that's installed. In that case, you
have to use the old-fashioned (i.e. simple and reliable) method of
testing for the features that you want rather than the version you
think has them.

To do a version check, libbraiding would have to supply a pkg-config
(*.pc) file. The pc file basically just encodes information, like the
version, about a package in a standard place. Sage would then run
pkg-config to read the file and get the installed version.

For version information alone, pkg-config is of dubious benefit, but
it has other uses like making it possible to install packages in
non-standard locations (say you need both gtk3 and gtk4 installed at
the same time). And if the *.pc file is there anyway, the easy thing
to do is use it.

[mmarco]

If I add a .pc file to libbraiding, would it interfere with the install location in the sage distribution?

[Dima Pasechnik]

Hi Miguel,

On Monday, November 4, 2024 at 10:15:01 AM UTC mmarco wrote:

If I add a .pc file to libbraiding, would it interfere with the install location in the sage distribution?

as long as it's done right, it will be of help.

It's a very short addition with autotools.

Feel free to ask me to do this for you, or I can review your changes.

Dima

[mmarco]

I have no experience on that whatsoever, so if you could do ir (or guide me with it), i would really appreciate it.

[Dima Pasechnik]

Please see https://github.com/miguelmarco/libbraiding/pull/4

> --
> 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 visit https://groups.google.com/d/msgid/sage-devel/2eff5554-7eab-408f-9b88-0b557be4c21an%40googlegroups.com.

[mmarco]

Thank you! I just made a new release with the pkg-config support