- Feb 24, 2025
-
-
Matt Harbison authored
With `py -3.9 contrib/packaging/packaging.py wix --pyoxidizer-target x86_64-pc-windows-msvc`, there is an immediate failure after building the venv (3.9.13 has `setuptools` 58.1.0): ModuleNotFoundError: No module named 'setuptools.command.build' With that fixed, the same command then fails immediately with this error: Couldn't import setuptools_scm (direct call of setup.py?) Unfortunately, referencing `setuptools` in the requirements file needs `--allow-unsafe` to avoid a warning about not pinning `setuptools`. However, the same warning happens if `setuptools` is pinned to a specific revision, so I have no idea what it is complaining about. It's a separate venv that is only used for packaging, so we can fix it if it becomes a problem in the future. Interestingly, the Inno installer build doesn't fail immediately, and I can see it installing `setuptools` and `setuptools_scm` in the wall of text it emits. Eventually it does fail with the same errors without this change.
-
- Feb 17, 2025
-
-
Pierre-Yves David authored
We are using the wrong name.
-
- Feb 11, 2025
-
-
Mathias De Mare authored
-
Mathias De Mare authored
-
Mathias De Mare authored
-
- Feb 06, 2025
-
-
Mathias De Mare authored
-
- Feb 04, 2025
-
-
Mathias De Mare authored
-
Mathias De Mare authored
-
Mathias De Mare authored
-
- Feb 03, 2025
-
-
Mathias De Mare authored
-
Mathias De Mare authored
-
- Feb 04, 2025
-
-
Mathias De Mare authored
-
- Feb 03, 2025
-
-
Mathias De Mare authored
This is useful when trying to run docker builds with host platforms that cannot build a recent hg (for example RHEL8 and derivatives).
-
Mathias De Mare authored
-
- Feb 17, 2025
-
-
Matt Harbison authored
This is more conventional.
-
- Dec 19, 2024
-
-
Matt Harbison authored
Same as for the Windows migration in the prior commit, but we need to override the architectures supported in CI, because the current CI system is too old to support building arm64 binaries. The shell script did (and still does) build universal2 wheels, because it's run on a different system that's isolated from the CI system. Already, it's obvious that these platform scripts were slightly diverging (e.g. this macOS one didn't specify the set of python targets). Also, the CI target for macOS is doing something strange- it's looping over its own list of targets and building them, but not in a parallel matrix. Linux is doing something similar, but in a standalone shell script. I suspect we can call `cibuildwheel --print-build-identifiers` to let it figure out what should be built based on the config file settings, and then feed each identifier to `cibuildwheel --only $ID`. But let's save that for now for simplicity.
-
Matt Harbison authored
This might seem to be of dubious utility, but this was the change that I was working up to- the ability to produce all of the wheels in a single command. The problem before was that the *.bat file ran two different commands, so when it printed the summary at the end, the summary of the first command was lost in the middle of a wall of text. That made it harder to check that updating to VS 2022 wasn't failing or skipping something in the older Pythons. Even though Python 3.8 on Windows doesn't support arm64, it's smart enough to skip that configuration, so there's no need to conditionalize it. (Yes, that means the *.bat file could have been condensed into one command without this, but since we support the same python versions for all platforms, I think it makes sense to capture them in one place here.) Unlike the previous commits, `heptapod-ci.yml` isn't changed because that's building things in parallel (though that may not be real useful on Windows or macOS where there's only one runner that allows 2 concurrent jobs). The environment variables defined in the CI config will override the config settings here.
-
- Dec 18, 2024
-
-
Matt Harbison authored
This was only known to be needed on Windows, but we don't run tests anywhere through `cibuildwheel`, so disable it. Environment variables override config file options[1], so if these one-off scripts want to have `cibuildwheel` make a venv, install the wheel, and run the test suite, they can override this. [1] https://cibuildwheel.pypa.io/en/stable/options/#overrides
-
Matt Harbison authored
Let's have one source of truth, whether building manually or through CI. https://cibuildwheel.pypa.io/en/stable/options/#configuration-file
-
- Jan 30, 2025
-
-
Matt Harbison authored
I noticed this when running `py hghave` on a system that still has Python2- the Windows launcher attempts to honor the version of python in the shebang, but `hghave` recently gained py3 type annotations, so that resulted in a SyntaxError. I guess CI has the compat shim installed to redirect `python` to `python3`, and maybe that's why nobody noticed. These were located by grepping for `#!.+python\b`. The remaining handful of cases are tests trying to find python files, which is fine as-is. The one thing to call out here is that apparently the RPM building hasn't worked with Python3 (or we've been getting lucky). `contrib/hg-ssh` has had a python3 shebang line since late 2020, which means the EOL anchor would have caused it to not match and not be replaced with `%{pythonexe}`. OTOH, it looks like that variable was used prior to the `hg-ssh` update in order to default to python3 (as opposed to using a specific /path/to/pythonX), and maybe the update to `hg-ssh` simply broke python2 builds. I'm not going to worry about this for now, since there are also direct calls to `setup.py`, which no longer work as of this release cycle. Somebody interested in RPMs can figure out all of the issues at once.
-
- Jan 02, 2025
-
-
Matt Harbison authored
COPYING.rtf has a few additional changes (like the website URL), because it's been unmaintained for awhile now.
-
- Nov 16, 2024
-
-
Matt Harbison authored
This is mostly a translation of `contrib/packaging/build-windows-wheels.bat`, except the default pythons to build can be inferred from `setup.py` and/or `pyproject.toml`, and all use the same configuration. All we need to do is force the building of translation files, tell it to skip pypy wheels, and tell it to build universal2 wheels instead of for the current architecture.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
The embarrassing details of how this was discovered will be kept under silence.
-
Pierre-Yves David authored
We no longer run the test while building wheels as they are build the very same ways as in the CI (that run tests).
-
- Nov 14, 2024
-
-
Matt Harbison authored
This is duplicated from the current CI config, to be able to build releases consistently outside of CI. I don't like the duplication, but I'm not worried about things changing too often, so I'm not bothering with PowerShell or some form that would allow execution by the CI runner. We should consider putting the config in `pyproject.toml`, where things like what python versions to support can be centrally controlled for all platforms. The output directory is different from CI here, but that's fine because it is intended to run this on a system that is *not* hosting the CI setup, and `dist/` is more standard. I dropped the `win32` part of the output because that implies the 32-bit Intel architecture. Apparently, arm64 builds are supported back to Python 3.9, but support is still experimental (with py3.13)[1]. The CI system starts arm64 support with Python 3.11, because that's the first version that an arm64 Python installer was available on Windows. This doesn't second guess that decision. The required `msgfmt.exe` was installed manually[2], as it isn't currently handled by the dependency installation script. Otherwise, this was successfully used with an activated venv based on Python 3.12.5, and only `cibuildwheel==2.21.3` installed. [1] https://cibuildwheel.pypa.io/en/stable/#what-does-it-do [2] https://github.com/mlocati/gettext-iconv-windows/releases/download/v0.22.5a-v1.17-r3/gettext0.22.5a-iconv1.17-shared-64.exe
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
We now have image to make that work.
-
- Nov 14, 2024
-
-
Pierre-Yves David authored
These can be installed on alpine… which is quite useful.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
This will make introduction of more variant simpler and testing quicker
-
Pierre-Yves David authored
It is currently broken.
-
Pierre-Yves David authored
The image should now have the proper config set globally to access this
-
Pierre-Yves David authored
We also make is a bit narrower so that it is less surprising.
-
- Nov 12, 2024
-
-
Pierre-Yves David authored
This reuse the script extracted in the previous changeset and now build the wheels with the same image and code as the CI.
-
- Sep 10, 2024
-
-
Pierre-Yves David authored
As discussed on the mailing list¹, these are old version that seems safe to drop. Python 3.8 comes with various improvement especially regarding typing capabilities. [1] https://lists.mercurial-scm.org/pipermail/mercurial-devel/2024-July/297998.html
-
- Jul 12, 2024
-
-
Anton Shestakov authored
-
- Dec 06, 2022
-
-
Matt Harbison authored
Otherwise, we get a bunch of test failures for missing things like pygments, or tests skipped entirely. The input file is a copy/paste from the equivalent Windows file, but with dulwich, pygit2, and pytest-vcr commented out because the build process errors out with them, flagging them as incompatible with loading from memory. I have no idea if that's actually true or not, because I've noticed that if I don't `make clean` after every build, the next build flags the watchman stuff as incompatible with loading from memory. The remaining failures are: Failed test-alias.t: output changed Failed test-basic.t: output changed Failed test-check-help.t: output changed Failed test-commit-interactive.t: output changed Failed test-extension.t: output changed Failed test-help.t: output changed Failed test-i18n.t: output changed Failed test-log.t: output changed Failed test-qrecord.t: output changed Failed test-share-safe.t: output changed Most of the issues seem related to loading help for disabled extensions from `hgext.__index__`, namely the full extension help being unavailable, not being able to resolve what commands are provided by what extension, and not having the command level help available. test-log.t, test-commit-interactive.t, and test-i18n.t look like i18n (or lack thereof) issues. test-basic.t is just odd: @@ -55,7 +55,7 @@ On Python 3, stdio may be None: $ hg debuguiprompt --config ui.interactive=true 0<&- - abort: Bad file descriptor (no-rhg !) + abort: response expected abort: response expected (rhg !) [255] $ hg version -q 0<&-
-
- Jan 02, 2023
-
-
Matt Harbison authored
-
- Nov 02, 2022
-
-
Jason R. Coombs authored
Also, add some documentation to the `.in` files.
-
- Sep 06, 2022
-
-
Matt Harbison authored
The presence of `certifi` causes the system certificate store to be ignored, which was reported as a bug against TortoiseHg[1]. It was only pulled in on Windows because of `dulwich`, which was copied from the old TortoiseHg install scripts, in order to support `hg-git`. This version of `dulwich` raises the minimum `urllib3` to a version (1.25) that does certificate verification by default, without the help of `certifi`[2]. We already bundle a newer version of `urllib3`. Note that `certifi` can still be imported from the user site directory, if installed there. But the installer no longer disables the system certificates by default. [1] mercurial/tortoisehg/thg#5825 [2] https://github.com/jelmer/dulwich/issues/1025
-
- Aug 08, 2022
-
-
Mathias De Mare authored
-
Mathias De Mare authored
-