Skip to content
Snippets Groups Projects
  1. Jan 23, 2025
  2. Jan 08, 2025
    • Pierre Augier's avatar
      packaging: modernize (compat PEP 517) with less distutils and setup.py calls · f5091286
      Pierre Augier authored
      - setup.py: less distutils imports and setuptools required
      
      distutils is deprecated and one should import commands from setuptools to support
      modern workflows depending on PEP 517 and 518.
      
      Moreover, for Python >=3.12, distutils comes from setuptools. It corresponds to old and
      unmaintain code that do not support PEP 517.
      
      The PEP 517 frontends (pip, build, pipx, PDM, UV, etc.) are responsible for creating a
      venv just for the build. The build dependencies (currently only setuptools) are specified
      in the pyproject.toml file. Therefore, there is no reason to support building without
      setuptools.
      
      Calling directly setup.py is deprecated and we have to use a PEP 517 frontend.
      For this commit we use pip with venv.
      
      - run-tests.py: install with pip instead of direct call of setup.py
      
      Mercurial is then built in an isolated environment.
      
      - Makefile: use venv+pip instead of setup.py
      f5091286
  3. Dec 15, 2024
    • Georges Racinet's avatar
      rust-pyo3: initial port of PySharedRef · be765f67
      Georges Racinet authored
      At this point, we have a full translation, with some tests.
      The tests are high level, demonstrating the case of iterating over
      `HashSet` as a doctest. The assertions are written as Python statements,
      in order not to be obscure and to resist later refactorings.
      The rust-cpython integration tests will be ported in a subsequent changeset.
      
      We find the example of iterating over `HashSet` to be more convincing than
      the iterating over `Vec`, the example provided in rust-cpython, because
      in the case of `Vec`, it would be simple enough to use `Arc<Vec>` and
      an index. This would of course be reimplementing the iterator, but is simple
      enough that it leads the reader to believe that having a reference is the
      problem, whereas the problem is having a reference that is itself enclosed
      in a type with lifetime that can be arbitrary complex. It took us some
      time to remember that subtlety, and hence we reworded the documentation
      to stress that point.
      
      We decided to put this work a separate crate, which makes running `cargo test`
      work for the crate, but not for the entire workspace: the `extension-module`
      feature gets in the way. That is why we reexpose the feature on `hg-pyo3` as
      default and run the tests with `--no-default-feature` in Makefile, hence in CI.
      
      An important difference with rust-cpython is that everything has to be `Sync`,
      hence we replace `RefCell` with `RwLock` and only speak of "interior mutability"
      in the documentation. Since everything happens in `hg-pyo3` behind the GIL,
      there is at this point no reason to use `read()` and `write()` instead of
      respectively `try_read()` and `try_write()`. But PyO3 is aiming to support
      free-threaded Python (without GIL), and `PySharedRef` should therefore
      allow waiting for its inner locks.
      be765f67
  4. Nov 15, 2024
  5. Nov 14, 2024
  6. Nov 15, 2024
  7. Jan 08, 2024
    • Anton Shestakov's avatar
      contrib: add a set of scripts to run pytype in Docker · 87bfd170
      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.
      87bfd170
  8. Feb 18, 2023
  9. 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
  10. Jan 25, 2023
    • Raphaël Gomès's avatar
      clippy: actually fail if there are any warnings · 3c37cb7b
      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.
      3c37cb7b
  11. Jan 10, 2023
  12. Dec 05, 2022
    • Matt Harbison's avatar
      make: add a target for building pyoxidizer tests on macOS · d5b722ce
      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.
      d5b722ce
  13. Aug 08, 2022
  14. Mar 25, 2022
  15. Mar 03, 2022
  16. Feb 15, 2022
  17. Aug 17, 2021
  18. Aug 18, 2021
  19. Aug 17, 2021
  20. Mar 25, 2021
  21. Mar 10, 2021
  22. Nov 24, 2020
  23. Nov 21, 2020
    • Matt Harbison's avatar
      make: switch the PYTHON default to `py.exe -3` on Windows · 4f6816e8
      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
      4f6816e8
  24. Nov 06, 2020
  25. Sep 01, 2020
  26. Oct 06, 2020
    • Gregory Szorc's avatar
      makefile: use Python 3 by default (BC) · c2837640
      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
      c2837640
  27. 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
  28. Aug 08, 2020
  29. Jan 29, 2020
  30. Nov 22, 2019
  31. Nov 07, 2019
  32. Nov 04, 2019
Loading