1374644 - update DXR's mercurial version

Status: RESOLVED FIXED

(Webtools Graveyard :: DXR, defect)

Description

[Kendall Libby [:fubar] (he/him)]

DXR has a pinned requirement on Mercurial==3.4.2. This should really be updated to at least match hg.mozilla.org (4.1.2).

It's currently causing an issue trying to get clonebundles working properly. Something is calling hg to update the clones and getting DXR's version, instead of /usr/bin/hg (4.1.3), and throwing errors. I'm not sure what it is, as I've updated the docker entrypoint script to use the full path, but updating DXR is still the correct thing to do.

Comment 1

[Kendall Libby [:fubar] (he/him)]

And, naturally, even using /usr/bin/hg is unhappy as apparently THAT version (from the community PPA) uses the system python, which then induces the following error: warning: connecting to hg.mozilla.org using legacy security technology (TLS 1.0); see https://mercurial-scm.org/wiki/SecureConnections for more info

It's just a warning, but YA reason.

Comment 2

[Kendall Libby [:fubar] (he/him)]

ugh, too many bugs. see https://bugzilla.mozilla.org/show_bug.cgi?id=1374546#c2 for test errors related to trying to switch to hg 4.2.1

Comment 3

[Erik Rose [:erik][:erikrose]]

DXR uses a custom hg plugin to efficiently keep track of the last commit in which each file changed. It's crashing now. Working on it.

Comment 4

[[github robot]]

Commit pushed to master at https://github.com/mozilla/dxr

https://github.com/mozilla/dxr/commit/323c4960816c5c7a0b9c9cb5b1d1bdd11b6662ee
Update hg version to 4.2.1. Fixes bug 1374644.

Make hg extension compatible with hg 4.2.1. Follow the (weird, pathologically introspective, scribbly-on-globals) idiom from https://www.mercurial-scm.org/wiki/WritingExtensions#Command_table. The @command decorator fills in the attrs of the function that hg is expecting and throwing AttributeErrors over.

Update hglib while we're at it.

Comment 5

[Erik Rose [:erik][:erikrose]]

It still makes me nervous that something is running the copy of hg in DXR's virtualenv. I suspect it's due to to the virtualenv being activated, which prepends the venv's bin folder to PATH. In general, I recommend we keep the venv activated for the shortest possible scope; there are several other binaries in there, not least of all Python itself, with a bevy of libs that the system is not expecting and probably without a bevy that it is. If we're activating it at the container level as part of the dockerfile, we ought to stop. Actually, we should never have to activate it explicitly; running /the/venv/bin/dxr will run DXR with the venv active just for that command.

Comment 6

[Kendall Libby [:fubar] (he/him)]

Things like comm-* clone and update mozilla-central as part of 'mach build' which is part of the build_command in dxr.config (never mind the bazillion other things mach is doing there). I'm not sure how to go about deactivating the venv without also jumping through lots of hoops...

Comment 7

[Erik Rose [:erik][:erikrose]]

Ah, that is tricky. At least that explains it; I was nervous because I thought we didn't understand what was going on. I think we're fine. Thanks, Fubar.