- 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
-
- Nov 01, 2019
-
-
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.
-
- Oct 31, 2019
-
-
kiilerix authored
Fedora 31 has just been released, and Fedora 29 will be EOL in a month. Don't spend any time thinking about dead stuff.
-
- Oct 14, 2019
-
-
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.
-
- Aug 21, 2019
-
-
Raphaël Gomès authored
While no particular minimum toolchain version is targeted as of yet, this serves as a first step to make more people/machines run the Rust tests.
-
- Apr 04, 2019
-
-
Philippe Pepiot authored
Use "?=", otherwise the variable cannot be set from environment.
-
- Dec 06, 2018
-
-
Georges Racinet authored
The existing behaviour, building the direct ffi bindings if HGIWTHRUSTEXT is just set is unchanged, but if HGWITHRUSTEXT is cpython, then the cpython bindings (aka mercurial/rustext.so) are built. Differential Revision: https://phab.mercurial-scm.org/D5436
-