Skip to content
Snippets Groups Projects
  1. Apr 11, 2023
  2. Dec 01, 2023
  3. Jan 25, 2023
    • Franck Bret's avatar
      commands: add admin namespace · 727428c7
      Franck Bret authored
      In order to stop abusing the 'debug' namespace for non-debug command,
      it adds a new 'admin' namespace dedicated to 'admin' operations on a
      repository (i.e commands suitable for administration tasks).
      
      This namespace entry would be used to migrate in the future some
      existing commands from the 'debug' namespace, or other top level
      commands that may not be directly exposed to end users.
      (verify command is a perfect candidate for this case)
      727428c7
  4. Sep 06, 2023
  5. Sep 04, 2023
    • Arseniy Alekseyev's avatar
      setup: make the error "Unable to find a working hg binary" more informative · 5dc7e190
      Arseniy Alekseyev authored
      The error message now shows the attempted hg commands and their stderr, to
      make it easier to investigate why things are not working.
      
      Here's an example output
      
      /!\
      /!\ Unable to find a working hg binary
      /!\ Version cannot be extracted from the repository
      /!\ Re-run the setup once a first version is built
      /!\ Attempts:
      /!\   attempt #0:
      /!\     cmd:         ['hg-missing', 'log', '-r.', '-Ttest']
      /!\     exception:   [Errno 2] No such file or directory: 'hg-missing': 'hg-missing'
      /!\   attempt #1:
      /!\     cmd:         ['/usr/bin/python3', 'hg', 'log', '-r.', '-Ttest']
      /!\     return code: 255
      /!\     std output:
      /!\     std error:
      *** failed to import extension "topic": No module named 'topic'
      *** failed to import extension "evolve": No module named 'evolve'
      abort: accessing `dirstate-v2` repository without associated fast implementation.
      (check `hg help config.format.use-dirstate-v2` for details)
      /!\
      /!\ Could not determine the Mercurial version
      /!\ You need to build a local version first
      /!\ Run `make local` and try again
      /!\
      5dc7e190
  6. Jul 21, 2023
  7. Jan 23, 2023
    • Raphaël Gomès's avatar
      configitems: declare items in a TOML file · c51b178b
      Raphaël Gomès authored
      Mercurial ships with Rust code that also needs to read from the config.
      Having a way of presenting `configitems` to both Python and Rust is needed
      to prevent duplication, drift, and have the appropriate devel warnings.
      
      Abstracting away from Python means choosing a config format. No single format
      is perfect, and I have yet to come across a developer that doesn't hate all of
      them in some way.
      Since we have a strict no-dependencies policy for Mercurial, we either need
      to use whatever comes with Python, vendor a library, or implement a custom
      format ourselves.
      
      Python stdlib means using JSON, which doesn't support comments and isn't great
      for humans, or `configparser` which is an obscure, untyped format that nobody
      uses and doesn't have a commonplace Rust parser.
      Implementing a custom format is error-prone, tedious and subject to the
      same issues as picking an existing format.
      
      Vendoring opens us to the vast array of common config formats. The ones
      being picked for most modern software are YAML and TOML. YAML is older and
      common in the Python community, but TOML is much simpler and less error-prone.
      I would much rather be responsible for the <1000 lines of `tomli`, on top of
      TOML being the choice of the Rust community, with robust crates for reading it.
      
      The structure of `configitems.toml` is explained inline.
      c51b178b
    • Raphaël Gomès's avatar
      thirdparty: vendor tomli · 2c34c9b6
      Raphaël Gomès authored
      The next commit will introduce a .toml file to abstract configitems
      away from Python. Python 3.11 has a toml read-only library (`tomllib`), which
      gives us a way out of vendoring eventually.
      
      For now, we vendor the backport, specifically version 1.2.3 which is still
      compatible with Python 3.6.
      2c34c9b6
  8. Jun 27, 2023
  9. May 24, 2023
    • Pierre-Yves David's avatar
      rewrite: simplify the `retained_extras` extra logic · cbcbf63b
      Pierre-Yves David authored
      First, we move the definition of value outside of the rebase extensions, as this
      apply to all rebase-like operation and some live in other place (like evolve).
      
      Second we make it a simple set, so that it is easy for an extension to add a new
      value in it.
      
      Third, we move the associated logic in core too. That make it easily available
      to other extensions.
      
      Fourth we simplify it usage, as the verbose version of the filtering is just a
      handful on line long, we are just going to test all the value for updates, so
      the Projection overlay is not bringing much here.
      
      Note that, we make it a module level set, is a key is worth preserving it is
      probably worth preserving in all cases. This was already the behavior prior to
      this change.
      cbcbf63b
  10. Mar 30, 2023
    • Euxane TRAN-GIRARD's avatar
      stabletailgraph: implement stable-tail sort · f0d2b18f
      Euxane TRAN-GIRARD authored
      This adds the computation of the "stable-tail sort", an incremental node
      sorting method. It is a stepping stone for the implementation of faster
      label discovery (for example for obs markers) and more caching.
      f0d2b18f
  11. Mar 22, 2023
  12. Feb 22, 2023
  13. Feb 18, 2023
  14. Feb 17, 2023
    • Pierre-Yves David's avatar
      setup: further improve the error path for version retrieval · 010a1e73
      Pierre-Yves David authored
      This is a new take at the problem that 8d390a13474d tried to tackle. There was
      two issues after that previous improvement:
      
      - the 0.0+ version could survive a bit too long and reaching the installer
        version and staying there.
      - multiple use case where still failing.
      
      So the new code is better at:
      - always succeeding when running `make local` so that we can
        bootstrap a local version
      - no using that fallback outside of `make local` to avoid distribution of
        version with the buggy version number.
      
      The setup.py is a gigantic pile of spaghetti code, to the point where
      pastafarian pilgrim started knocking at its core.
      
      However I refrained from cleaning that up since the more to a `setup.cfg` means
      this code should be deleted soon™.
      010a1e73
  15. Jan 31, 2023
  16. Jan 30, 2023
    • Pierre-Yves David's avatar
      setup: treat error output and non-zero return code differently · ac93876e
      Pierre-Yves David authored
      Choking on Mercurial's stderr mean armless warning can derails the whole install
      process. We do like to be able to issue warning to people so we stop considering
      any stderr is a fatal mistake.
      
      This allow us to actually boostrap a version of Mercurial without loosing to
      many sanity point. For example in case where evolve is not loaded, something
      that happens when the recorded version is malformatted. Creating a wonderful
      ouroboros.
      ac93876e
    • Pierre-Yves David's avatar
      setup: make the version computation process more resistant · 8d390a13
      Pierre-Yves David authored
      The tag fetching might return and empty string¹, from there everything derails
      quickly. As setup tools becomes more picky about version format we make the
      whole seems a bit more robust.
      
      The resulting version will be obviously weird, but at least it will actually
      install itself.
      
      [1] This is a problem we will address in the next changesets.
      8d390a13
  17. Jan 28, 2023
  18. Jan 04, 2023
    • Matt Harbison's avatar
      setup: drop legacy osx compiler tuning to enable universal builds · dd804d83
      Matt Harbison authored
      This was triggering deprecation warnings about migrating to `packaging.version`
      from `distutils` Version classes with `make local`.  But rather than migrate
      that code, let's just get rid of some ~10-12 year old workarounds.  As a bonus,
      the cext libraries that are built are now universal binaries containing x86_64
      and arm64 images (at least when built on macOS 11.4 with Xcode 12.5 and the
      universal version of Python 3.9.13).
      
      Several things to note here:
      
         - Apple dropped support for 10.15 in Nov 2022, and OS X Lion that is
           referenced is 10.7 (unsupported since late 2014)
         - `xcode4` was basically always True because of the `>=` check (10.8 used
           Xcode 5, and I have Xcode 10.2 on 10.14)
         - `xcode51` was always False for modern-ish Xcode, because of the exact
           version string matching
         - Python 3.8 only supports OS X 10.9+; the Python 3.9.1+ universal installer
           is macOS 11+ only, and Python 3.10 drops the x86_64 installer to deliver
           only the universal installer.
      
      All of this is to say, the only thing lost by dropping this code on modern Xcode
      is that `os.environ['ARCHFLAGS'] = ''` is no longer set.  But we probably
      shouldn't be setting that anymore, as shown by the universal libraries now being
      generated.  I was able to `make local` and `python3 run-tests.py --local` with
      python 3.9.9, Xcode 10.2, and macOS 10.14.6, and didn't incur any more than the
      usual few test errors, so this should still work on some older versions of
      macOS.
      dd804d83
    • Raphaël Gomès's avatar
      branching: merge stable into default · e0c0545e
      Raphaël Gomès authored
      e0c0545e
  19. Jan 02, 2023
  20. Nov 24, 2022
    • Matt Harbison's avatar
      setup: include vendored 3rd party type stubs · 54421ef8
      Matt Harbison authored
      While pytype may not support PEP 561, PyCharm does, so having the stubs
      available means it can determine `foo = attr.ib(type=int)` means `foo` is an
      int.  This only applies when using Mercurial as a library, like with TortoiseHg
      development- PyCharm is already smart enough to use the *.pyi files in the
      Mercurial source tree when hacking on Mercurial itself.
      
      I left the mercurial.cext stubs out because it seems very low level, that 3rd
      parties shouldn't be using directly.
      54421ef8
  21. Jul 18, 2022
    • Matt Harbison's avatar
      setup: use the full executable manifest from `python.exe` · ece490b0
      Matt Harbison authored
      The manifest embedded by the build process (before the string here is added)
      already accounts for the `<requestedExecutionLevel level="asInvoker" ...>`
      setting.  (Note that the PyOxidizer build is missing this, so it will likely
      trigger the UAC escalation prompt on each run.)  However, using `mt.exe` to
      merge the fragment with what is already in the manifest seems to strip all
      whitespace, making it unreadable.
      
      Since Mercurial can be run via `python.exe`, it makes sense that we would have
      the same manifest settings (like the supported OS list), though I'm unaware of
      any functionality this enables.  It also has the nice effect of making the
      content readable from a resource editor.  The manifest comes from python 3.9.12.
      
      Note that this seems to strip the `<?xml ... ?>` declaration when viewed with
      ResourceHacker 5.1.7, but this was also the state of things with the previous
      commit, and `mt.exe "-inputresource:hg.exe;#1" -out:extracted` does contain the
      declaration and the BOM in both cases.  No idea why this differs from other
      executables.
      ece490b0
    • Matt Harbison's avatar
      setup: unconditionally enable the `long-paths-support` option on Windows · 747c4fc2
      Matt Harbison authored
      I don't see anything talking about why this was experimental in the first place,
      but maybe it was concern about the level of python2 support for it.  But now,
      both `python.exe` and the PyOxidizer build of `hg.exe` have a manifest that
      enables it, so leaving it off would mean some Mercurial installations could
      operate on a repo with long paths, and others couldn't.  Note that only the wide
      character functions (XxxW) will have the length restriction lifted.
      
      Sadly, distutils applies `/MANIFEST:EMBED` to the linker in a way that can't
      easily be turned off, so we can't use `/MANIFESTFILE` with `extra_preargs` on
      `link_executable`.  Fortunately, the compiler object provides a path to the
      `mt.exe` it found during initialization, because the previous incarnation seems
      to have assumed it is being run within an activated Visual Studio environment.
      That causes MSYS builds to fail, and probably would have broke the CI
      environment.
      747c4fc2
    • Matt Harbison's avatar
      setup: stop shadowing the builtin `dir` symbol · 5cf73de9
      Matt Harbison authored
      I hit this when debugging what's available on the compiler.
      5cf73de9
  22. May 31, 2022
  23. Apr 13, 2022
    • Matt Harbison's avatar
      setup: fix the py2exe logic to work with py3 · 97f2554c
      Matt Harbison authored
      TortoiseHg still uses (the modernized) py2exe packaging, but the build was
      failing since `py2exe.Distribution` was removed.
      
      One thing to note is that later in this module, there's a hack to include
      `distutils` when building from a virtualenv.  While `import distutils` works in
      `hg debugshell` when built with py2, it doesn't work in py3.  I'm not sure why-
      I don't see it in `library.zip` either.  It doesn't seem to break anything
      though.
      
      Differential Revision: https://phab.mercurial-scm.org/D12553
      97f2554c
  24. Apr 07, 2022
  25. Mar 25, 2022
  26. Feb 21, 2022
  27. Mar 03, 2022
  28. Mar 02, 2022
Loading