Skip to content
Snippets Groups Projects
  1. May 06, 2021
    • Gregory Szorc's avatar
      pyoxidizer: support code signing · c8001d9c
      Gregory Szorc authored
      Newer versions of PyOxidizer feature built-in support for
      code signing. You simply declare a code signer in the Starlark
      configuration file, activate it for automatic signing, and
      PyOxidizer will add code signatures to signable files as it
      encounters them.
      
      This commit teaches our Starlark configuration file to enable
      automatic code signing. But only on Windows for the moment, as our
      immediate goal is to overhaul the Windows packaging.
      
      The feature is opt-in: you must pass variables to PyOxidizer's
      build context via `pyoxidizer build --var` or
      `pyoxidizer build --var-env` to activate code signing.
      
      Differential Revision: https://phab.mercurial-scm.org/D10684
      c8001d9c
    • Gregory Szorc's avatar
      pyoxidizer: support producing MSI installers · 603efb38
      Gregory Szorc authored
      Newer versions of PyOxidizer have support for building WiX MSI
      installers "natively." Essentially, you can script the definition
      of your WiX installer via Starlark and PyOxidizer can invoke
      WiX tools to produce the installer.
      
      This commit teaches our PyOxidizer config file to produce MSI
      installers similarly to how
      `contrib/packaging/packging.py wix` would do it.
      
      We had to make a very minor change to `mercurial.wxs` to reflect
      different paths depending on who builds. This is because when
      PyOxidizer builds WiX installers, it does so from an isolated
      directory, not Mercurial's source directory. We simply copy the
      files into the build environment so they are accessible.
      
      After this change, running `pyoxidizer build msi` produces a nearly
      identical install layout to what the previous method produces.
      When I applied this series on top of the 5.8 tag, here is the
      list of differences and explanations:
      
      * docs/*.html files are missing from the new installer because the
        Python build environment doesn't have docutils.
      * .pyd and .exe files differ, likely because I'm using a different
        Visual Studio toolchain on my local computer than the official build
        environment.
      * Various .dist-info/ directories have different names. This is
        because older versions of PyOxidizer had buggy behavior and weren't
        properly normalizing package names in .dist-info/ directories. e.g.
        we went from `cached-property-1.5.2.dist-info` to
        `cached_property-1.5.2.dist-info`.
      * Translations (.mo files) may be missing if gettext isn't in %Path%.
        This is because the packaging.py code installs gettext and ensures
        it can be found.
      * Some *.dist-info/RECORD files vary due to SHA-256 content digest
        divergence due to build environment differences. (This should be
        harmless.)
      * The new install layout ships a python3.dll because newer versions
        of PyOxidizer ship this file.
      * The new install layout has a different vcruntime140.dll and also a
        vcruntime140_1.dll because newer versions of PyOxidizer ship a
        newer version of the Visual C++ Redistributable Runtime.
      
      The new PyOxidizer functionality is not yet integrated with
      packaging.py. This will come in a subsequent commit. So for now, the
      new functionality introduced here is unused.
      
      Differential Revision: https://phab.mercurial-scm.org/D10683
      603efb38
    • Gregory Szorc's avatar
      pyoxidizer: use allocator_backend instead of raw_allocator · 3380848c
      Gregory Szorc authored
      The name of this attribute changed in PyOxidizer 0.11.
      
      Differential Revision: https://phab.mercurial-scm.org/D10682
      3380848c
    • Gregory Szorc's avatar
      pyoxidizer: simplify targets · 9438e9b7
      Gregory Szorc authored
      The split targets existed to enable the use of a non-default
      distribution flavor on Windows. Modern versions of PyOxidizer
      use the "standalone_dynamic" distribution flavor by default.
      So our split brain workaround is no longer needed.
      
      Here, we unify the targets. We also remove an unreferenced
      target function to create a resources file.
      
      Differential Revision: https://phab.mercurial-scm.org/D10681
      9438e9b7
    • Gregory Szorc's avatar
      contrib: install PyOxidizer 0.16.0 · 0de5eefb
      Gregory Szorc authored
      PyOxidizer now provides MSI installers and pre-built Linux binaries.
      So we install that way. This significantly reduces the time to bootstrap
      a new machine in automation, as building PyOxidizer from source on a low
      core count machine takes several minutes.
      
      This change temporarily breaks the ability of the automated environment
      to use the in-repo pyoxidizer.bzl configuration file, as there are
      backwards-incompatible changes with the upgrade that need to be
      reflected. We'll handle those in subsequent commits.
      
      Differential Revision: https://phab.mercurial-scm.org/D10680
      0de5eefb
    • Gregory Szorc's avatar
      pyoxidizer: pin Python to 3.8 · 95950dc8
      Gregory Szorc authored
      Newer versions of PyOxidizer use version 3.9 by default. As part of
      upgrading PyOxidizer, we want to pin the version at 3.8 so we can
      compare differences more easily.
      
      Differential Revision: https://phab.mercurial-scm.org/D10679
      95950dc8
    • Gregory Szorc's avatar
      pyoxidizer: remove some boilerplate in file · 3e18a29d
      Gregory Szorc authored
      This isn't used for anything and can safely be removed.
      
      Differential Revision: https://phab.mercurial-scm.org/D10678
      3e18a29d
    • Gregory Szorc's avatar
      contrib: upgrade Rust in Windows automation · b128a3ae
      Gregory Szorc authored
      I'm not sure why we don't install the minimum required Rust version
      here like we do for Linux. Whatever: that's unrelated to wanting to
      stay modern.
      
      Differential Revision: https://phab.mercurial-scm.org/D10677
      b128a3ae
    • Gregory Szorc's avatar
      contrib: update Python versions in Windows automation · e768294a
      Gregory Szorc authored
      Let's keep our Python versions modern.
      
      Differential Revision: https://phab.mercurial-scm.org/D10676
      e768294a
    • Gregory Szorc's avatar
      automation: update rust in Linux environment · 2df655f6
      Gregory Szorc authored
      Our minimum supported Rust is 1.41.1 per rust/README.rst. We also
      bump the modern Rust version to latest stable to stay current.
      
      Differential Revision: https://phab.mercurial-scm.org/D10675
      2df655f6
    • Gregory Szorc's avatar
      automation: install latest Python versions in Linux environment · 743522fa
      Gregory Szorc authored
      Let's keep our Linux environment up to date.
      
      Differential Revision: https://phab.mercurial-scm.org/D10674
      743522fa
  2. May 07, 2021
    • Gregory Szorc's avatar
      automation: create Python 3.5 variant of requirements.txt · 546e812a
      Gregory Szorc authored
      The automation environment is refusing to build with the previous
      file because some dependencies won't install on Python 3.5.
      
      I couldn't find an easy way to salvage the situation with a single
      requirements.txt file. So, I decided to introduce a variant
      for Python 3.5.
      
      As part of this, we update packages to latest versions.
      
      (I do question why we are still supporting Python 3.5...)
      
      Differential Revision: https://phab.mercurial-scm.org/D10690
      546e812a
  3. May 15, 2021
  4. May 10, 2021
  5. May 11, 2021
  6. Apr 15, 2021
  7. Apr 16, 2021
  8. Apr 15, 2021
  9. May 11, 2021
  10. May 08, 2021
    • Matt Harbison's avatar
      run-tests: use the same python version for shebang lines on Windows · 6f976d54
      Matt Harbison authored
      The latest py3 is used if the minor number isn't specified.  After running the
      script to install all of the build dependencies, that moved the default from 3.8
      to 3.9 on the CI system.  That in turn caused a bunch of tests to be skipped
      that were running prior, even when the test runner was invoked with `py -3.8`.
      While we should almost always use the latest version, we really shouldn't make
      it hard to test different versions or allow things to randomly break in subtle
      ways like that.
      
      Differential Revision: https://phab.mercurial-scm.org/D10702
      6f976d54
  11. May 14, 2021
  12. May 12, 2021
  13. May 03, 2021
Loading