Skip to content
Snippets Groups Projects
  1. Nov 28, 2020
  2. Nov 30, 2020
  3. Nov 26, 2020
    • Matt Harbison's avatar
      packaging: add pygit2 to the py3 Windows installers · d2649781
      Matt Harbison authored
      This is needed to be able to use the git extension.
      
      The extension no longer complains about the library being not installed, but
      `hg log -r .` on a repo that works in WSL yielded a TypeError:
      
            ...
            File "mercurial.hg", line 188, in _peerorrepo
            File "mercurial.localrepo", line 3224, in instance
            File "mercurial.localrepo", line 623, in makelocalrepository
            File "hgext.git", line 117, in _makestore
            File "hgext.git", line 48, in __init__
          TypeError: Repository unable to unpack backend.
      
      Differential Revision: https://phab.mercurial-scm.org/D9405
      d2649781
  4. Nov 24, 2020
    • Matt Harbison's avatar
      packaging: drop Disco (19.04) and add Focal (20.04) · 97142451
      Matt Harbison authored
      Disco support ended in January 2020, and Focal does not have an announced EOL.
      
      Something is now installing and configuring `tzdata`, which was throwing up an
      interactive prompt to configure the timezone.  Aside from being hostile to
      automation, the prompt didn't actually accept input and hung the process.  This
      propagates the host's timezone into the image via environment variable in order
      to skip the prompt, and avoid hardcoding a value.
      
      Differential Revision: https://phab.mercurial-scm.org/D9396
      97142451
    • Matt Harbison's avatar
      packaging: add `HG_DOCKER_OWN_USER` to `dockerdeb` like exists in `dockerrpm` · f6a1540d
      Matt Harbison authored
      I was getting build failures when it was trying to write to the working
      directory on CentOS 7 without this.  It is basically the same as was added to
      the RPM builder in 4c0d4bbdc395.
      
      For some reason, this doesn't work with Xenial, and the only solution I found
      was to invoke it with UID 1000 on the host side.  It doesn't EOL until April
      2024, but it also has python 3.5.2, so this build complication is the least of
      the problems with supporting it after py2 is dropped.
      
      Differential Revision: https://phab.mercurial-scm.org/D9394
      f6a1540d
  5. Nov 29, 2020
  6. Nov 28, 2020
  7. Nov 27, 2020
    • durin42's avatar
      formating: upgrade to black 20.8b1 · 89a2afe3
      durin42 authored
      This required a couple of small tweaks to un-confuse black, but now it
      works. Big formatting changes come from:
      
       * Dramatically improved collection-splitting logic upstream
       * Black having a strong (correct IMO) opinion that """ is better than '''
      
      Differential Revision: https://phab.mercurial-scm.org/D9430
      89a2afe3
  8. Nov 11, 2020
    • Mathias De Mare's avatar
      packaging: enable rust extensions on centos · eccbfa7e
      Mathias De Mare authored
      Test on CentOS 7, repository with ~170000 tracked files,
          no untracked files:
      10 runs with this enabled:
       -- Run #0 time: 0.6519973278045654
       -- Run #1 time: 0.6933724880218506
       -- Run #2 time: 0.7512078285217285
       -- Run #3 time: 0.7517638206481934
       -- Run #4 time: 0.5966529846191406
       -- Run #5 time: 0.5960886478424072
       -- Run #6 time: 0.5940573215484619
       -- Run #7 time: 0.5963726043701172
       -- Run #8 time: 0.6048009395599365
       -- Run #9 time: 0.603604793548584
      
      10 runs without this enabled:
       -- Run #0 time: 2.127584457397461
       -- Run #1 time: 2.066192865371704
       -- Run #2 time: 2.0831892490386963
       -- Run #3 time: 2.077716588973999
       -- Run #4 time: 2.07608962059021
       -- Run #5 time: 2.072899341583252
       -- Run #6 time: 2.094369888305664
       -- Run #7 time: 2.067504644393921
       -- Run #8 time: 2.069610834121704
       -- Run #9 time: 2.0567898750305176
      
      Differential Revision: https://phab.mercurial-scm.org/D9294
      eccbfa7e
  9. Nov 26, 2020
  10. Nov 25, 2020
  11. Nov 22, 2020
  12. Nov 20, 2020
  13. Nov 06, 2020
  14. Nov 02, 2020
  15. Oct 22, 2020
    • Gregory Szorc's avatar
      automation: upload Python 3.9 Windows wheels · d1ce0ffd
      Gregory Szorc authored
      We are producing these. We should be publishing them.
      d1ce0ffd
    • Gregory Szorc's avatar
      contrib: split Windows requirements into multiple files · d270b9b7
      Gregory Szorc authored
      Package support for Python 2 has diverged significantly. It is no
      longer trivial to maintain a single requirements file that supports
      both Python 2 and 3 because the set of packages and versions varies
      wildly.
      
      This commit split up the Windows requirements files so we have
      variants for Python 2 and 3. As part of this, I also renamed the
      files to have what I believe to be more reasonable naming ("win32"
      felt like a weird identifier to me).
      
      We can see that some package versions decreated on 2.7. This is
      because the old pinned versions weren't compatible with Python 2.
      d270b9b7
  16. Oct 19, 2020
  17. Oct 09, 2020
  18. Oct 05, 2020
    • Gregory Szorc's avatar
      pyoxidizer: produce working Python 3 Windows installers (issue6366) · 57b5452a
      Gregory Szorc authored
      While we've had code to produce Python 3 Windows installers with
      PyOxidizer, we haven't been advertising them on the web site due to
      a bug in making TLS connections and issues around resource handling.
      
      This commit upgrades our PyOxidizer install and configuration to
      use a recent Git commit of PyOxidizer. This new version of PyOxidizer
      contains a *ton* of changes, improvements, and bug fixes. Notably,
      Windows shared distributions now mostly "just work" and the TLS bug
      and random problems with Python extension modules in the standard
      library go away. And Python has been upgraded from 3.7 to 3.8.6.
      
      The price we pay for this upgrade is a ton of backwards incompatible
      changes to Starlark.
      
      I applied this commit (the overall series actually) on stable to
      produce Windows installers for Mercurial 5.5.2, which I published
      shortly before submitting this commit for review.
      
      In order to get the stable branch working, I decided to take a
      less aggressive approach to Python resource management. Previously,
      we were attempting to load all Python modules from memory and were
      performing some hacks to copy Mercurial's non-module resources
      into additional directories in Starlark. This commit implements
      a resource callback function in Starlark (a new feature since
      PyOxidizer 0.7) to dynamically assign standard library resources
      to in-memory loading and all other resources to filesystem loading.
      This means that Mercurial's files and all the other packages we ship
      in the Windows installers (e.g. certifi and pygments) are loaded
      from the filesystem instead of from memory. This avoids issues
      due to lack of __file__ and enables us to ship a working Python
      3 installer on Windows.
      
      The end state of the install layout after this patch is not
      ideal for @: we still copy resource files like templates and
      help text to directories next to the hg.exe executable. There
      is code in @ to use importlib.resources to load these files and
      we could likely remove these copies once this lands on @. But for
      now, the install layout mimics what we've shipped for seemingly
      forever and is backwards compatible. It allows us to achieve the
      milestone of working Python 3 Windows installers and gets us a
      giant step closer to deleting Python 2.
      
      Differential Revision: https://phab.mercurial-scm.org/D9148
      57b5452a
    • Gregory Szorc's avatar
      packaging: normalize - to _ in WiX Id values · 439ce34d
      Gregory Szorc authored
      - is not a valid identifier character in WiX Ids. So let's
      normalize accordingly.
      
      I discovered this issue after a subsequent change which introduces
      a directory with a - in its name.
      
      Differential Revision: https://phab.mercurial-scm.org/D9147
      439ce34d
  19. Oct 03, 2020
  20. Oct 04, 2020
  21. Oct 05, 2020
  22. Oct 01, 2020
    • Martin von Zweigbergk's avatar
      rust: move rustfmt.toml to repo root so it can be used by `hg fix` · 426294d0
      Martin von Zweigbergk authored
      `hg fix` runs the formatters from the repo root so it doesn't pick up
      the `rustfmt.toml` configs we had in each the `hg-core`, `hg-cpython`,
      and `rhg` packages, which resulted in warnings about `async fn` not
      existing in Rust 2015. This patch moves the `rustfmt.toml` file to the
      root so `hg fix` will use it.
      
      By putting the `rustfmt.toml` file in a higher-level directory, it
      also applies to the `chg` and `hgcli` packages. That makes
      `test-check-rust-format.t` fail, so this patch also applies the new
      formatting rules to those packages.
      
      Differential Revision: https://phab.mercurial-scm.org/D9142
      426294d0
  23. Sep 30, 2020
    • Raphaël Gomès's avatar
      rust: introduce `dirstate-tree` cargo feature · e604a3c0
      Raphaël Gomès authored
      This feature gates (at compile-time) the use of the newly-added dirstate tree.
      
      The motivation for this is that the dirstate tree is currently *very* slow;
      replacing the current hashmap-based dirstate is not a viable solution in terms
      of performance... and why would you be using the Rust implementation if not
      for performance?
      
      The feature will also help reviewers better understand the differences that
      will slowly appear as the dirstate tree gets better.
      
      Differential Revision: https://phab.mercurial-scm.org/D9132
      e604a3c0
  24. Sep 03, 2020
    • Valentin Gatien-Baron's avatar
      chg: make is possible to call by default an hg binary located next to chg · 4c8d9b53
      Valentin Gatien-Baron authored
      When a single version of hg is in use and it's in the PATH, using chg
      is just a matter of calling chg.
      
      But when there are multiple installations of hg+chg around, and hg is
      referred to with an absolute path, using chg is more annoying because
      it requires both changing the invocation to hg to use chg, but also
      setting CHGHG.
      
      Currently, we set HGPATH when we build chg to remove the need to set
      CHGHG in the previous paragraph. But that means chg now hardcodes its
      installation path, which makes the installation not relocatable. Hence
      this proposal to make chg find ./hg relative to itself (as opposed to
      CHGHG=./hg which find hg relative to cwd).
      
      This only works on linux as written, but since it's opt-in, it sounds
      fine.
      
      Tested by hand, as I'm not sure how else to test this.
      
      Differential Revision: https://phab.mercurial-scm.org/D9006
      4c8d9b53
  25. Sep 18, 2020
  26. Sep 02, 2020
    • haraldkl's avatar
      hgweb: compatibility of hgweb.cgi template with Python 3 · d58a205d
      haraldkl authored
      When running Mercurial on Python 3 hgweb expects the config variable to be a
      bytestring.
      The solution proposed by Anton Shestakov is to use a byteprefix to the literal
      string defined cgi script as provided in this patch for hgweb.cgi,
      contrib/hgweb.fcgi and contrib/hgweb.wsgi.
      I am not sure whether this covers all relevant templates, but I couldn't find
      others.
      
      Differential Revision: https://phab.mercurial-scm.org/D8978
      d58a205d
  27. Sep 01, 2020
  28. Jul 24, 2020
    • Kyle Lippincott's avatar
      tests: make check-py3-compat.py actually load the specified files correctly · 4e5da64d
      Kyle Lippincott authored
      For most uses, this change is essentially a no-op, as this script is generally
      only run by test-check-py3-compat.t, which will already put `$TESTDIR/..` in
      `$PYTHONPATH`.
      
      When running outside of tests, however, `$PYTHONPATH` is likely not set, causing
      check-py3-compat.py to parse the file from the repo, but then import the
      installed version, and raise any errors about the installed version, not the one
      currently in the repo.
      
      Additionally, this helps users (like me) who have a strange set up where their
      home directory (and thus their hg repos) happen to be in a subdirectory of
      sys.prefix (which is /usr on my system). Since the '.' entry added to sys.path
      takes precedence over the absolute path of `$TESTDIR/..` in `$PYTHONPATH`, the
      path to the modules that it imports (and that show up in any stack trace) are
      *relative*, meaning that we don't detect them as starting with `sys.prefix`.
      
      Sample non-test invocation, and the difference this change makes (the path for
      'error at <path>:<line>' is correct now)::
      
      Before:
      ```
      $ python3 contrib/check-py3-compat.py mercurial/win*.py
      mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at check-py3-compat.py:65)
      mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at check-py3-compat.py:65)
      ```
      
      After:
      ```
      $ python3 contrib/check-py3-compat.py mercurial/win*.py
      mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at win32.py:11)
      mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at windows.py:12)
      ```
      
      Differential Revision: https://phab.mercurial-scm.org/D8814
      4e5da64d
  29. Jul 06, 2020
Loading