Skip to content
Snippets Groups Projects
  1. Nov 15, 2024
  2. Nov 14, 2024
  3. Nov 15, 2024
  4. Jan 08, 2024
    • Anton Shestakov's avatar
      contrib: add a set of scripts to run pytype in Docker · 87bfd1703597
      Anton Shestakov authored
      Having a simple way to run pytype for developers can massively shorten
      development cycle. Using the same Docker image and scripts that we use on our
      CI guarantees that the result achieved locally will be very similar to (if not
      the same as) the output of our CI runners.
      
      Things to note: the Dockerfile needs to do a little dance around user
      permissions inside /home/ci-runner/ because:
      
      - on one hand, creating new files on the host (e.g. .pyi files inside .pytype/)
        should use host user's uid and gid
      
      - on the other hand, when we run the image as uid:gid of host user, it needs to
        be able to read/execute files inside the image that are owned by ci-runner
      
      Since local user's uid might be different from ci-runner's uid, we execute this
      very broad chmod command inside /home/ci-runner/, but then run the image as the
      host user's uid:gid.
      
      There might be a better way to do this.
      87bfd1703597
  5. Feb 18, 2023
  6. Feb 17, 2023
    • Pierre-Yves David's avatar
      setup: further improve the error path for version retrieval · 010a1e73f69e
      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™.
      010a1e73f69e
  7. Jan 25, 2023
    • Raphaël Gomès's avatar
      clippy: actually fail if there are any warnings · 3c37cb7bce61
      Raphaël Gomès authored
      So far, only errors would trip the CI, this makes it so all warnings are
      elevated to errors, making it a CI fail if any warnings are present.
      This was the intended behavior, I just missed this when adding clippy.
      3c37cb7bce61
  8. Jan 10, 2023
  9. Dec 05, 2022
    • Matt Harbison's avatar
      make: add a target for building pyoxidizer tests on macOS · d5b722ce9864
      Matt Harbison authored
      The resources seem to be embedded inside the binary, but for some reasons they
      aren't read there.  And since they are embedded, they aren't staged by the build
      in the `lib` directory like on Windows.  So copy them from the repo.  We can
      figure out what's going wrong later.
      d5b722ce9864
  10. Aug 08, 2022
  11. Mar 25, 2022
  12. Mar 03, 2022
  13. Feb 15, 2022
  14. Aug 17, 2021
  15. Aug 18, 2021
  16. Aug 17, 2021
  17. Mar 25, 2021
  18. Mar 10, 2021
  19. Nov 24, 2020
  20. Nov 21, 2020
    • Matt Harbison's avatar
      make: switch the PYTHON default to `py.exe -3` on Windows · 4f6816e8440b
      Matt Harbison authored
      Python3 _is_ named `python.exe` on Windows, but that isn't necessarily on PATH
      when installing from python.org.  I do happen to have a python.exe on PATH in
      `$LOCALAPPDATA/Microsoft/WindowsApps`, but it appears to be 0 bytes (likely
      because of permission issues), and doesn't run:
      
          $ python -V
           - Cannot open
      
      Pulkit hit the same error as I did though, so it isn't just my system:
      
          $ make -C . local
          make: Entering directory `/home/Dell/repos/hg-committed`
          python setup.py  \
                    build_py -c -d . \
                    build_ext  -i \
                    build_hgexe  -i \
                    build_mo
           - Cannot openmake: *** [local] Error 1
      
      The `py.exe` dispatcher lives in the Windows directory (so it is on PATH), looks
      up the python.org installation, and invokes that interpreter directly.  I get a
      warning with py39, but if it's our issue, it was an existing one:
      
          $ make -C .. local
          make: Entering directory `/c/Users/Matt/hg'
          py -3 setup.py  \
                    build_py -c -d . \
                    build_ext  -i \
                    build_hgexe  -i \
                    build_mo
          C:\Users\Matt\AppData\Local\Programs\Python\Python39\lib\site-packages\setuptools\distutils_patch.py:25:
              UserWarning: Distutils was imported before Setuptools. This usage is discouraged and may
              exhibit undesirable behaviors or errors. Please use Setuptools' objects directly or at least
              import Setuptools first.
            warnings.warn(
      
      The end result is a py3 based hg.exe that annoyingly won't run because it can't
      find python39.dll.  It will run tests (the ones without the `python3` shbang
      line anyway), because the test runner adjusts PATH to include the python running
      it.
      
      Differential Revision: https://phab.mercurial-scm.org/D9361
      4f6816e8440b
  21. Nov 06, 2020
  22. Sep 01, 2020
  23. Oct 06, 2020
    • Gregory Szorc's avatar
      makefile: use Python 3 by default (BC) · c2837640aeb0
      Gregory Szorc authored
      This change is long overdue IMO.
      
      .. bc::
      
         Makefile now uses `python3` instead of `python` by default on
         non-Windows platforms. This means Mercurial will be built and
         run with Python 3 instead of Python 2.7 by default.
      
         To continue using Python 2, set the PYTHON variable. e.g.
         `make install PYTHON=python2.7`.
      
      Differential Revision: https://phab.mercurial-scm.org/D7258
      c2837640aeb0
  24. Sep 30, 2020
    • Raphaël Gomès's avatar
      rust: introduce `dirstate-tree` cargo feature · e604a3c03ab9
      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
      e604a3c03ab9
  25. Aug 08, 2020
  26. Jan 29, 2020
  27. Nov 22, 2019
  28. Nov 07, 2019
  29. Nov 04, 2019
  30. Nov 01, 2019
    • kiilerix's avatar
      packaging: refactor "fedora29" target to a single more generic "fedora" target · 0b65f18edc4f
      kiilerix authored
      Fedora moves fast in version numbers, and often with Mercurial packaging being
      backwards compatible. Also, most people use the system package. There is thus
      much work and tech debt and little value in providing explicit built-in support
      for several versions. Thus, only aim for providing built-in support for latest
      Fedora version, and make it easy to update.
      0b65f18edc4f
  31. Oct 31, 2019
  32. Oct 14, 2019
    • Yuya Nishihara's avatar
      rust-cpython: prepare for writing tests that require libpython · 8d432d3a2d7c
      Yuya Nishihara authored
      What I wanted is to disable the "cpython/extension-module<ver>" feature
      while building tests executable, but that seems not doable. Instead,
      this patch adds new features dedicated for tests.
      
      The make rule is extracted so that we can easily run cargo tests.
      
      Added a minimal test of ref-sharing as an example. More tests will follow.
      8d432d3a2d7c
Loading