Hi Ludovic, always glad to hear of hg.sr.ht ! On 8/17/24 10:04 PM, Ludovic Chabant wrote:
Hey there!We had some fun incident over at hg.sr.ht caused, mostly, it seems, by the Alpine mercurial package disabling and re-enabling the Rust extensions for a couple releases:
ouch, that hurts.
Python 3.12 support has since then been done in rust-cpython indeed. I'm not sure what the support level of 3.12 is overall in Mercurial.https://git.alpinelinux.org/aports/log/community/mercurial/APKBUILD In the git log above, note the 6.7.3 and 6.7.4 releases sandwiched between commits that disabled/re-enabled the Rust extensions. Judging from the comments on the first commit, they did this because of this bug: https://github.com/dgrunwald/rust-cpython/issues/294
But anyway, the problem is that Rust was enabled before, and so some of our customers' repositories started using persistent nodemaps. When the Rust extensions were disabled by the package upgrade, we started running into errors, because it looks like Mercurial defaults to "abort" when persistent nodemaps are encountered without the Rust extensions being present. We solved it temporarily by setting `storage.revlog.persistent-nodemap.slow-path` to `warn`, system-wide. I wonder if `warn` should be the default behaviour? There are other Mercurial features that still "work with a warning" when stuff is missing, such as obsolete tags found without evolve being activated. Is there a good reason to default to "abort" in the case of persistent nodemaps?
I agree that it is very inconvenient.The persistent nodemap stores the mapping from "Node IDs", i.e., hashes of changesets to the corresponding revision number, which is the actual identifier internally used in most Mercurial code [1].
The problem is that although the persistent nodemap has a pure Python implementation (as it must), it is expected to be unbearably slow, probably to the point that Mercurial would appear not to work above a not-so-high repository size (nobody did try to measure that to my knowledge). This implementation was done for reference and to support the test suite, with no attempt to optimize it. It is anyway very likely that even the best possible pure Python version would make Mercurial much slower than not using any persistent nodemap at all. And of course, disabling the persistent nodemap and re-enabling it is making an inconsistent repository. Think of what could happen in a mixed systems environment using some remote mounts, where some would have the Rust extension, and some would not (perhaps because their platform does not have a Rust toolchain). This is probably not what could happen in sr.ht, but Mercurial has to think of such use cases as well.
In Heptapod, what we are doing is installing Mercurial with something that boils down to `$PYTHON setup.py install --rust` [2] This is painful, we had to do it in several places, such as base CI images and the like, not even to speak of having the proper Rust toolchain installed (currently 1.73, soon-to-be if I remember correctly what Raphaël told me 1.79). But it is worth the price. Of course installing anything that depends on Mercurial before that makes a mess.
To hijack on another discussion that I have still not properly contributed to, yes I'd like to see Mercurial wheels, with the Rust variant if possible. As far as I understand, the Mercurial project is not yet decided on how such variants could be accommodated in the future.
[1] Actually, it's more general than the changelog, being applicable to any revlog (hence also manifestlog and filelogs)
[2] actually `pip install --no-use-pep517 --global-option --rust Mercurial`, but that is unsupported in recent versions of Pip. It seems they do not want any options. I'm not sure if the distribution variants with brackets still exist (would have been `Mercurial[rust]` in our case).
-- Georges Racinet https://orbeet.io/a-propos/cloudcrane, https://heptapod.net GPG: 09719FFE0B476DC26923F8EEB8EB20361976F291
OpenPGP_0xB8EB20361976F291.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mercurial mailing list Mercurial@lists.mercurial-scm.org https://lists.mercurial-scm.org/mailman/listinfo/mercurial
