- Nov 28, 2024
-
-
Pierre-Yves David authored
Lets do it all in one place and at the start, this is easier to maintain consistently. We also take this as an opportunity to do this before we resolve commit options, that so user do not get error about "--date" when they actually they specified the "--current-date" argument.
-
- Nov 20, 2024
-
-
Pierre-Yves David authored
We don't use it in that function, so I would rather have it close to the return.
-
Pierre-Yves David authored
Now that the dust as settled a bit, we can make things a bit clearer.
-
Pierre-Yves David authored
That one is not preserved in the statefile, so we can explicitly pass it as argument.
-
Pierre-Yves David authored
Same logic as before.
-
Pierre-Yves David authored
Same logic as before.
-
Pierre-Yves David authored
The goal is for the graft logic to not deal with the command line option, so lets to reinjecting value in these config option.
-
- Nov 19, 2024
-
-
Pierre-Yves David authored
This starts splitting the two logic more cleanly and avoid one spilling in the other. This will be useful to introduce more way to do the grafting, e.g. "in memory". For now, there is still a lot spilling from one to another, but this will get cleaned over time.
-
Pierre-Yves David authored
The "mercurial.commands" have been overweight for a while. We create a namespace dedicated to host smaller modules containing code revelant to a specific command. This should result in more isolated snd manageable module. We start with moving the code for "hg graft" in "mercurial.cmd_impls.graft" before doing more work on it. Since that code was about 5% of "commands.py" this seems like a success.
-
- Nov 28, 2024
-
-
Matt Harbison authored
-
- Nov 27, 2024
-
-
Matt Harbison authored
It seems like this command doesn't currently cause the wheels to be cached, but since I already had to prevent `pip` from caching when building wheels in 1a09563a615c, and also disable it in a test in 30b5dc517ec2, let's just be explicit that we don't want caching, in case the default behavior changes.
-
Matt Harbison authored
After 1a09563a615c, there's one more wheel that gets cached in the user's pip cache in the macOS CI runner. The wheel corresponds to the version being used for the tests, but it doesn't get cached until the 3rd or 4th test shard is run, so it's not an issue with installing to run the tests. This seems to eliminate that. This doesn't seem to be an issue on Windows or Linux in my setup. Windows not being affected is likely because we set `$USERPROFILE` to redirect the home directory to `$TESTTMP` when running tests, since 08fd76a553c9. (When checking with `"$PYTHON" -m pip cache dir`, it points to `$TESTTMP/pip/cache`.) We do also set `$HOME` to this same location when running posix tests, but I can't tell what's going on locally in Linux, because running `pip` directly in the *.t explodes, and `"$PYTHON" -m pip --version` prints `pip 9.0.1 from /usr/lib/python3/dist-packages`, so that's likely before caching was enabled[1]. Running `python3.8 -m pip --version` locally outside of the *.t (the same version used to invoke the test runner), prints `pip 24.2 from /home/mharbison/.local/lib/python3.8/site-packages/pip (python 3.8)`. In CI, both macOS and Linux print a modern version of `pip`, and list the cache as being under `$TESTTMP`, but then it doesn't end up there on macOS. No idea if it is a pip bug, or what. But let's be explict and disable caching. [1] https://github.com/pypa/pip/blob/fe0925b3c00bf8956a0d33408df692ac364217d4/docs/html/topics/caching.md?plain=1#L37
-
- Oct 23, 2024
-
-
Pierre Augier authored
-
- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 24, 2024
-
-
Pierre Augier authored
-
- Nov 23, 2024
-
-
Pierre Augier authored
-
- Oct 23, 2024
-
-
Pierre Augier authored
This is redundant with requires-python in pyproject.toml.
-
Pierre Augier authored
-
- Nov 27, 2024
-
-
Matt Harbison authored
I had a pile of these one-shot wheels cached on the mac, taking about 1.2G of space from the few weeks we've been building wheels to test, and with the few times the macOS tests were actually run. There's not much point in caching these, since the tests run from a wheel file the tests are force fed. There is still an issue with one wheel from the tests being cached (probably on install), but that's 1/6 of the original problem. I'm putting this in the `pyproject.toml` because I think that's where we should have all of the `cibuildwheel` config collected. There's a concurrent effort to modernize `setup.py` and use this file more, so I'll hold off on pushing most of the config in here for now. But this applies the setting to all OSes, as well as when run through either CI or the individual buid scripts, so I think this is clearly the right way to go. Note that the docs for `cibuildwheel` talks about the intention to move from `pip` to `build` some day. This config only covers the former, so the other config example[1] with the latter may be needed at some point. But I don't see an obvious option for that tool, so we'll cross that bridge when we come to it. [1] https://cibuildwheel.pypa.io/en/v2.22.0/options/#examples_6
-
- Oct 21, 2024
-
-
Pierre Augier authored
-
- Nov 21, 2024
-
-
Matt Harbison authored
Before it was optional, and either 1.1 or 1.2 was sufficient. Now that the default minimum is 1.2, it needs to be present to work out of the box. The code here is more convoluted than the corresponding checks in `sslutil.py`, but I'm leaving it alone because it can all be simplified when py38 is dropped.
-
Matt Harbison authored
Simple enough, and then we don't need comments to cross-reference other areas of code that need to be kept in sync. Since the `_getreplacements()` list is now partially dynamically generated and needed to change anyway, also move the one line that was being appended separately to the list for some reason, for clarity.
-
- Nov 18, 2024
-
-
Dan Villiom Podlaski Christiansen authored
-
- Nov 04, 2024
-
-
Raphaël Gomès authored
It is fully replaced with the now stable `std::io::IsTerminal` trait. This was the last dependency flagged as a warning by `cargo audit`, aside from `cpython` which we know about all too well: the plan is to transition to PyO3 soon-ish.
-
Raphaël Gomès authored
Aside from being more up-to-date in general, this makes its own dependency on the unmaintained and now useless `atty` disappear.
-
Raphaël Gomès authored
This brings in more up-to-date dependencies, some bug fixes (none of which are relevant yet), and slightly improved compile times.
-
Raphaël Gomès authored
It makes sense to keep our doc build happy, even if it is lacking.
-
Raphaël Gomès authored
All compressors should be `Send`, might as well make any future use easier.
-
Raphaël Gomès authored
The `compress` function is unlikely to be used in highly contended situations, and creating a compressor has some overhead, on top of losing out on some potential advantages of longer-running optimizations from the compressor.
-
Raphaël Gomès authored
This only muddies the lib and makes the imports more confusing.
-
Raphaël Gomès authored
This is where it belongs
-
Raphaël Gomès authored
That's where they belong and should always have been there.
-
Raphaël Gomès authored
This was done very early in the Rust project's lifecycle and I had very little Rust experience. Let's keep the `DirstateParents` since they'll pop up in all higher-level code and make the rest more explicit imports to make the imports less confusing and the lib less cluttered.
-
Raphaël Gomès authored
This makes the crate's imports confusing and muddies the discovery of the code.
-
Raphaël Gomès authored
The historical reasonning for `dirstate_tree` existing in the first place is that a new approach was needed for the tree-like dirstate and it was easier to start somewhat fresh. Now that the former dirstate is (long) gone, we can merge those two modules to avoid the confusion that even the module creators sometimes get.
-
Raphaël Gomès authored
This is more explicit.
-
Raphaël Gomès authored
This is more explicit.
-