- Feb 28, 2025
-
-
Anton Shestakov authored
Let's repeat 42baf12efd21.
-
- Feb 22, 2025
-
-
Pierre-Yves David authored
Now that all user has been removed, we can safely drop them.
-
- Jan 14, 2025
-
-
Matt Harbison authored
PyCharm was complaining about that the previous code was a statement with no effect. This avoids that warning, and hopefully also appeases whatever linter was complaining about an unused import.
-
- Jan 13, 2025
-
-
Matt Harbison authored
Even fewer complaints from PyCharm now.
-
Matt Harbison authored
That's how PyCharm was seeing it because of the default param, so it was flagging the callers that passed an int. Fewer yellow ticks are better (26 remain).
-
Matt Harbison authored
This started failing in CI because a str was passed. All other callers already pass bytes, and it's not clear why this started failing with a MR to use `setuptools-scm` to derive the version when building. Clearly the `if checks["hg09"][0]()` prior to these usages were working before, and that's how it was overlooked. But that check apparently continued to work for me locally in both Linux and Windows, as I can only hit this issue in CI.
-
- Jan 06, 2025
-
-
Matt Harbison authored
These were different classes in py2, but now a handful of error classes are just an alias of `OSError`, like `IOError`, `EnvironmentError`, `WindowsError`, etc. This is the result of running a hacked version of `pyupgrade` 3.19.1[1] $ hg files -0 'relglob:**.py' | xargs -0 \ pyupgrade --py38-plus --keep-percent-format --keep-mock --keep-runtime-typing The hack is because it doesn't have command line switches to disable most changes, so it makes tons of unrelated changes all at once. The hack is to 1) patch `pyupgrade._main._fix_tokens()` to immediately return its content arg 2) change `pyupgrade._data.register_decorator()` to only register the function if it's from the fixer we're interested in: if func.__module__ in ( "pyupgrade._plugins.exceptions", ): FUNCS[tp].append(func) return func [1] https://github.com/asottile/pyupgrade
-
- Dec 28, 2024
-
-
Matt Harbison authored
For some reason, I can't reproduce this on either of my laptops, even when `black` isn't on `PATH`. But it was happening on the Windows CI system (where `black` isn't installed at all), and this was the exception raised.
-
- Dec 18, 2024
-
-
Matt Harbison authored
This demonstrates the alternate way of testing for the proper version that was mentioned in the last commit. Needing to manually evaluate from the project root when run in the test suite is a bit unfortunate. Arguably it is limiting for 3rd party users, but they were already locked into a specific version before too, if using this sentinel. This lock-in is only for the version check though, and then they can `cd /path/to/repo` to run their `test-*.t` with their config. On the plus side, we're allowing any minor variant of the required major version, we're not assuming the version string format that the tool produces, and there's one source of truth for the version. If running under `RUNTESTDIR` is omitted, then `hghave` will allow any version as long as the tool exists on `PATH`, but `test-check-format.t` will fail with the message in the previous commit. I'd argue that's preferrable to suddenly quietly skipping the test when the requirement changes, but this was the previous behavior too, so that's maintained here.
-
- Dec 22, 2020
-
-
Matt Harbison authored
AFAICT, all of the TLS versions are supported by the server without doing any explicit work, and there's only a `devel` config to specify an exact version on the server side. Clients would also use TLSv1.3 if available, but this prevents the server from negotiating down. This also causes "tls1.3" to be listed in `hg debuginstall`, even though it was previously supported (if the Python intepreter supported it- IDK if there's a good way to proactively test for and show future protocols without requiring manual updates like this). The v1.3 tests are nested inside the v1.2 tests for simplicity. The v1.2 blocks already assume v1.0 and v1.1 support, so this seems reasonable for now. If/when the older protocols start getting dropped, this will have to be reworked anyway.
-
- Oct 26, 2024
-
-
Matt Harbison authored
test-fix-clang-format.t suddenly started failing on Windows by wiping the whole file content, and replacing with an error: $TESTTMP.sh: $TESTTMP.sh: cannot execute binary file Odd, because I don't have `clang-format` installed, so the test should be skipped. The problem started with 73cf8b56c2f5, and I noticed that running `hghave` manually resulted in a `SyntaxError` (so I can't see how this isn't broken everywhere, but maybe it's because I'm using py3.9 on Windows): $ py hghave --list Traceback (most recent call last): File "hghave", line 8, in <module> import hghave File "c:\Users\Matt\hg\tests\hghave.py", line 627 SyntaxError: Non-ASCII character '\xe2' in file c:\Users\Matt\hg\tests\hghave.py on line 627, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
-
Pierre-Yves David authored
-
- Jun 29, 2023
-
-
kiilerix authored
When invoking StrictVersion in 3.12 we got: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. distutils is dead in the standard library, and we have to move towards using `setuptools` as general extern dependency. Instead of also requiring the extern `packaging`, we will just use the packaging that is vendored in setuptools.
-
- Oct 23, 2024
-
-
Pierre-Yves David authored
The usage of pyflakes as a Python module was introduced in e397c6d74652, to work around issue between Python 2 and Python 3. This issues are long behind us now and we can get beck to using pyflakes as a tool, giving us more flexibility about how we install it. The `hghave` requirements is modified to check that we have a tool available, instead of a python module.
-
- Oct 22, 2024
-
-
Pierre-Yves David authored
This gives me different formatting on latest version available in Debian. So disabling for now.
-
- Feb 05, 2019
-
-
Ludovic Chabant authored
In order to provide a useful error message to override the behavior, we also need to slightly change the way that tool.gui is found in the config. Before, it had to be where tool.diffargs is located, which might not exist. Now, tool.isgui can exist on its own. A test is added for the new error message. We also need to force procutil.isgui() to return true, so we set $DISPLAY to a non-empty value before running any test expecting to have a gui.
-
- Jun 26, 2023
-
-
kiilerix authored
When invoking StrictVersion in 3.12 we got: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. distutils is dead in the standard library, and we have to move towards using `setuptools` as general extern dependency. Instead of also requiring the extern `packaging`, we will just use the packaging that is vendored in setuptools.
-
- Jul 29, 2024
-
-
Raphaël Gomès authored
We still use nightly, but have moved to a newer nightly after the last CI image upgrade in 74f1bf147a6d and 3876d4c6c79e.
-
- Jul 18, 2024
-
-
Raphaël Gomès authored
The CI has moved to version 23.3.0, which is the last one to support 3.7 at runtime.
-
- Jul 23, 2024
-
-
Raphaël Gomès authored
I accidentally published 25e7f9dcad0f::bd1483fd7088, this is the inverse.
-
- Jul 18, 2024
-
-
Raphaël Gomès authored
The CI has moved to version 23.3.0, which is the last one to support 3.7 at runtime.
-
- Feb 02, 2024
-
-
Manuel Jacob authored
While not required in the core test suite in the moment, these could be useful in the future or for extensions. For example, Python 3.12 removed distutils and it might make sense to differentiate based on that.
-
Manuel Jacob authored
I think it’s a really bad idea to use floats for version numbers. One problem is that 3.10 is the same as 3.1.
-
Manuel Jacob authored
-
- Feb 28, 2023
-
-
Matt Harbison authored
These versions of python are no longer supported by Mercurial.
-
Matt Harbison authored
It looks like this predicate isn't used at all(?)
-
- Jan 25, 2023
-
-
Anton Shestakov authored
-
Anton Shestakov authored
There are 3 of them, and them all having the same name triggered code checkers.
-
Anton Shestakov authored
-
- Dec 06, 2022
-
-
Matt Harbison authored
There are a handful of tests with different output between the two flavors of pyoxidizer builds (like the location of the modules and templates), and a few others that avoid `known-bad-output` cases with the embedded resources that shouldn't cause the tests to fail.
-
- Dec 12, 2022
-
-
Anton Shestakov authored
Older versions (e.g. 2.7.2) say: "Usage: pylint [options]" Newer versions (e.g. 2.15.5) say: "usage: pylint [options]"
-
- Dec 11, 2022
-
-
Anton Shestakov authored
Some tests are already showing slightly different results on Python 3.11. The better idea would be to make them more portable, but if that's not possible, now we can use hghave detection for certain lines. I wonder if there will ever be Python 31.0 and 31.1 though.
-
Anton Shestakov authored
Noticed because test-contrib-relnotes.t was skipped.
-
- Nov 18, 2022
-
-
Arseniy Alekseyev authored
-
- May 29, 2022
-
-
Manuel Jacob authored
-
- Jun 08, 2022
-
-
Raphaël Gomès authored
-
- May 21, 2022
-
-
Manuel Jacob authored
Black commit 117891878e5be4d6b771ae5de299e51b679cea27 (included in black >= 21.11b0) dropped the string "version " from the output of "black --version". To make the regex work with newer black versions, make matching of "version " optional.
-
- Mar 03, 2022
-
-
Gregory Szorc authored
These were needed for Python 2 support. Now that our linter no longer mandates these, we can start deleting them. Differential Revision: https://phab.mercurial-scm.org/D12254
-
- Feb 16, 2022
-
-
Martin von Zweigbergk authored
-
- Feb 14, 2022
-
-
Raphaël Gomès authored
In 9ebc10ad4a04 I updated `rustfmt` without touching hghave, which means that the CI has been skipping the format test ever since. Thankfully, only one offending line exists in the code that's been introduced since. Differential Revision: https://phab.mercurial-scm.org/D12180
-