Skip to content
Snippets Groups Projects
  1. Feb 24, 2025
    • Matt Harbison's avatar
      contrib: add modern `setuptools` and `setuptools_scm` to the packaging venv · 0e2be2ab
      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.
      0e2be2ab
  2. Feb 17, 2025
  3. Feb 11, 2025
  4. Feb 06, 2025
  5. Feb 04, 2025
  6. Feb 03, 2025
  7. Feb 04, 2025
  8. Feb 03, 2025
  9. Feb 17, 2025
  10. Dec 19, 2024
    • Matt Harbison's avatar
      pyproject: migrate macOS `cibuildwheel` settings to pyproject.toml · 2642ef8e
      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.
      2642ef8e
    • Matt Harbison's avatar
      pyproject: migrate the Windows `cibuildwheel` settings to pyproject.toml · 505f6c5b
      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.
      505f6c5b
  11. Dec 18, 2024
  12. Jan 30, 2025
    • Matt Harbison's avatar
      py3: update the remaining shebang lines (mostly tests) to `python3` · f8f14e6d
      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.
      f8f14e6d
  13. Jan 02, 2025
    • Matt Harbison's avatar
      copyright: update to 2025 · 6ca5cf29
      Matt Harbison authored
      COPYING.rtf has a few additional changes (like the website URL), because it's
      been unmaintained for awhile now.
      6ca5cf29
  14. Nov 16, 2024
    • Matt Harbison's avatar
      contrib: add a script to build all of the wheels on macOS · 6aa4ee2b
      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.
      6aa4ee2b
  15. Nov 15, 2024
  16. Nov 14, 2024
    • Matt Harbison's avatar
      contrib: add a bat file to build all of the wheels on Windows · ea9cbb0f
      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
      ea9cbb0f
  17. Nov 15, 2024
  18. Nov 14, 2024
  19. Nov 15, 2024
  20. Nov 12, 2024
  21. Sep 10, 2024
  22. Jul 12, 2024
  23. Dec 06, 2022
    • Matt Harbison's avatar
      packaging: add dependencies to the PyOxidizer build on macOS · 3d7bf111
      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<&-
      3d7bf111
  24. Jan 02, 2023
  25. Nov 02, 2022
  26. Sep 06, 2022
    • Matt Harbison's avatar
      packaging: update dulwich to drop the certifi dependency on Windows · 37debd85
      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
      37debd85
  27. Aug 08, 2022
Loading