- Jan 23, 2025
-
-
Pierre Augier authored
Direct calls of setup.py should not be used. There is no equivalent to setup.py clean with PEP 517 frontends. We have to delete what we want ourself.
-
- Jan 08, 2025
-
-
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
-
- Dec 15, 2024
-
-
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.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
We now have image to make that work.
-
- Nov 14, 2024
-
-
Pierre-Yves David authored
These can be installed on alpine… which is quite useful.
-
- Nov 15, 2024
-
-
Pierre-Yves David authored
This is useful when using --jobs for example
-
- Jan 08, 2024
-
-
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.
-
- Feb 18, 2023
-
-
Pierre-Yves David authored
-
- Feb 17, 2023
-
-
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™.
-
- Jan 25, 2023
-
-
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.
-
- Jan 10, 2023
-
-
Raphaël Gomès authored
This linter mostly makes our code more idiomatic, less surprising, has good suggestions and catches bugs. It's widely used in the Rust community and now part of the default toolchain when using `rustup`.
-
Raphaël Gomès authored
There is no reason to only run inside the `rust/hg-cpython` folder, even if the `cargo test --all` behavior ends up being the same.
-
- Dec 05, 2022
-
-
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.
-
- Aug 08, 2022
-
-
Mathias De Mare authored
-
- Mar 25, 2022
-
-
Matthew Martin authored
Installs the bash and zsh completers to the convential locations so they will automatically be picked up without user intervention. The zsh completer on Debian is still installed to vendor-completions to match their policy. bash: https://github.com/scop/bash-completion#faq zsh: https://github.com/zsh-users/zsh/blob/57305cf245853b8b30895b41a90142dffab97e38/INSTALL#L254 Debian zsh: https://salsa.debian.org/debian/zsh/-/blob/5086b5356abcef8849dc8a09902b7c55f01db3c0/debian/README.Debian#L73
-
- Mar 03, 2022
-
-
Simon Sapin authored
Note: `cpython/python3-sys` is a default feature. Differential Revision: https://phab.mercurial-scm.org/D12316
-
- Feb 15, 2022
-
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D12182
-
- Aug 17, 2021
-
-
Pierre-Yves David authored
This get the hacky setup closer to how an actual install is setup. Differential Revision: https://phab.mercurial-scm.org/D11292
-
Pierre-Yves David authored
This get the hacky setup closer to how an actual install is setup. Differential Revision: https://phab.mercurial-scm.org/D11291
-
Pierre-Yves David authored
This get the hacky setup closer to how an actual install is setup. Differential Revision: https://phab.mercurial-scm.org/D11290
-
- Aug 18, 2021
-
-
Pierre-Yves David authored
This get the hacky setup closer to how an actual install is setup. Differential Revision: https://phab.mercurial-scm.org/D11289
-
- Aug 17, 2021
-
-
Pierre-Yves David authored
This fix about 10 extra test bring the number of currently failing test to about 12. Differential Revision: https://phab.mercurial-scm.org/D11287
-
Pierre-Yves David authored
We will need to setup more items to make the "quick" version work on stable, having a dedicated operation will allow to contains change to that operation. Differential Revision: https://phab.mercurial-scm.org/D11286
-
- Mar 25, 2021
-
-
Raphaël Gomès authored
Matt Mackall is now Olivia Mackall. I reached out to her about changing the copyright notices to reflect this change and she gave me the green light, so I changed everything relevant. Differential Revision: https://phab.mercurial-scm.org/D10266
-
- Mar 10, 2021
-
-
Pierre-Yves David authored
This gives and easy way to install rhg that we can use in `run-test.py` in the next changesets. Differential Revision: https://phab.mercurial-scm.org/D10194
-
Pierre-Yves David authored
This gives an easy action to build the rhg-binary. This will be useful for the `install-rhg` action in the next changeset. Differential Revision: https://phab.mercurial-scm.org/D10193
-
Pierre-Yves David authored
This is done as a gratuitous improvement on the way to add makefile entry to build and install rhg. It seems saner to have equivalent entry for chg too. Differential Revision: https://phab.mercurial-scm.org/D10192
-
Pierre-Yves David authored
This is done as a gratuitous improvement on the way to add makefile entry to build and install rhg. It seems saner to have equivalent entry for chg too. Differential Revision: https://phab.mercurial-scm.org/D10191
-
- Nov 24, 2020
-
-
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
-
Matt Harbison authored
These were removed from the packaging makefile in 0363bb086c57. Differential Revision: https://phab.mercurial-scm.org/D9395
-
- Nov 21, 2020
-
-
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
-
- Nov 06, 2020
-
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D9292
-
- Sep 01, 2020
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D9291
-
- Oct 06, 2020
-
-
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
-
- Sep 30, 2020
-
-
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
-
- Aug 08, 2020
-
-
Martin von Zweigbergk authored
The variable was added in a38ed42cd23c (osx: include chg by default, 2017-03-20), but I can't find any others references to the variable in that commit or in any other commits. Differential Revision: https://phab.mercurial-scm.org/D8915
-
- Jan 29, 2020
-
-
Matt Harbison authored
This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037
-
- Nov 22, 2019
-
-
Augie Fackler authored
I noticed this only because the WiX build was broken after 2e017696181f. I haven't tested this change with WiX, but it seems pretty obvious by inspection this should fix it. Differential Revision: https://phab.mercurial-scm.org/D7472
-
- Nov 07, 2019
-
-
Augie Fackler authored
Jessie is on life support at this point, so let's update the list of releases in the Makefiles. Differential Revision: https://phab.mercurial-scm.org/D7308
-
- Nov 04, 2019
-
-
Mathias De Mare authored
The resulting executable has not been tested in detail yet. I ran 'hg version' and 'hg clone', which worked fine (except for extensions acting up due to Python 3). Differential Revision: https://phab.mercurial-scm.org/D7216
-