bug#46925: Ripgrep tests failures due to bstr update

["JOULAUD François via Bug reports for GNU Guix" <bug-guix@gnu.org>]

Hello,

On Mon, Mar 08, 2021 at 10:40:27PM +0100, Nicolas Goaziou wrote:
> JOULAUD François via Bug reports for GNU Guix <bug-guix@gnu.org> writes:
> > Upgrade rust-bstr-0.2 to be 0.2.12, possibly only upgrading needed
> > dependent packages.
> 
> Just to be clear, your are suggesting a downgrade, because currently,
> Guix packages bstr 0.2.15. Downgrading is not trivial because bstr
> 0.2.15 is mandatory for bat 0.18.

My mistake here. I thought upstream ripgrep was using a more recent
version than the packaged one. Downgrade could indeed be more work.

> We might provide both bstr 0.2.12 and 0.2.15. Note that 11 packages are
> requiring bstr. Providing two bstr is only possible if none of those
> packages are both among bat and ripgrep dependencies. I didn't check but
> I'm not very optimistic.

I'm not either. ;-)

> > Patch new ripgrep to understand the old bstr debug format in its
> > tests.
> 
> I'll pass, sorry.

I understand that. TBH I don't volunteer for the work either even if in
this specific case it seems to be a pretty basic substitution and one
that upstream will need to do anyway when it will upgrade to new bstr.

> > Disabling tests is bad. Disabling tests when we diverge from supported
> > upstream configuration (in this cas as we don't use recommended version
> > of deps) is in my opinion even worst.
> 
> I'm not sure this kind of generalization helps here. Even if you may be
> right in theory, looking at the number of "#:tests #f" among packages,
> disabling tests is probably a necessary evil in practice.

I think it is a necessary evil. I just fear that it could become an
initial reflex when dealing with library incompatibility.

But you're probably right that this is a discussion for an other venue.

> Moreover, AFAICT, this incompatibility does not break functionality in
> ripgrep. It just breaks its tests. Disabling them for a while does not
> sound so bad, after all. Is it?

Yes, in this specific case it seems to only break tests without breaking
anything else (and I trust upstream explanation on this one). But at the
same time, if it ought to be breaking something else you know don't have
the tests to try to catch it.

Regards,
François