Make Mercurial command configurable by an environment variable #1144
Conversation
This makes it consistent with the other invocations in this file and makes it easier to parametrize the Mercurial command in the future.
|
Of course, I’m not quite happy with reloading the modules in the test. But it allows the non-test code to stay simple. Another possibility would be to monkey-patch the module-level constants, but I prefer testing the code like it is used by the user (who sets the environment variable) instead of depending on implementation details. |
manueljacob
force-pushed
the
hg_command
branch
2 times, most recently
from
881801b to
0c7a203
Compare
|
Why is it necessary to set a different hg command? I need a surrounding context |
manueljacob
force-pushed
the
hg_command
branch
2 times, most recently
from
8b26570 to
02472ab
Compare
|
See the commit messages. I’ll usually put motivations and other long explanations in the commit message for long-term record. If the pull request contains more than one commit, GitHub won’t automatically copy the commit message to the pull request description. |
|
Let's add a changelog entry for this and a example in the docs so users can quickly grasp it |
|
Okay, I will push a changelog entry. BTW, it was not obvious to me what the format of changelog entries in What would be a good example for the docs? I think developing Mercurial extensions is a bit too specific, so I guess it should be using |
|
In case of doubt ignore scriv i messed up correctly using it the last few releases I'll need a release prep bot to get that out of the door correctly |
You automated package version generation. Shouldn’t be too hard? ;) |
|
With github actions its a pain in the neck Like multiple 3rd party actions due to platform shortcomings At least its not gitlab |
@RonnyPfannschmidt Any opinion on the example? Otherwise, I’ll go ahead with the |
|
Chg is probably the best example Hevk it may make sense to use it as default if avaliable (with development caveats) |
This is useful when e.g. developing Mercurial or Mercurial extensions. Previously, the first ``hg`` binary in PATH was used. If the Mercurial in the current virtual environment was broken, it was impossible to install anything that uses setuptools-scm to determine a version from Mercurial. With this change, it is possible to set the SETUPTOOLS_SCM_HG_COMMAND environment variable to the standard system-wide Mercurial executable. Also, it makes it possible to make setuptools-scm use chg, a variant of Mercurial that uses a daemon to save start-up overhead. Using it, the time of running ``uv pip install`` of a small-to-medium-size package decreased from 8.826s to 2.965s (a 3x reduction). If the environment variable is not set, the behavior remains unchanged.
|
I pushed the updated documentation, adding a short motivation. We can separately discuss using |
| @@ -11,6 +11,7 @@ | |||
| from ._run_cmd import CompletedProcess as _CompletedProcess | |||
| from ._run_cmd import run as _run | |||
| from .git import GitWorkdir | |||
| from .hg import HG_COMMAND | |||
There was a problem hiding this comment.
Let's turn this into a module import to ease test instrumentation
| hg_exe: str, | ||
| ) -> None: | ||
| wd = repositories_hg_git[0] | ||
| with monkeypatch.context() as m: |
There was a problem hiding this comment.
Instead of reloading rhe modules lets turn the logic into a function the test can call
|
I plan to merge Monday as I'm mid travel |
No description provided.