run-tests: stuff a `python3.exe` into the test bin directory on Windows
Windows doesn't have `python3.exe` as part of the python.org distribution, and
that broke every script with a shebang after c102b704edb5. Windows itself
provides a `python3.exe` app execution alias[1], but it is some sort of reparse
point that MSYS is incapable of handling[2]. When run by MSYS, it simply prints
$ python3 -V
- Cannot open
That in turn caused every `hghave` check, and test that invokes shebang scripts
directly, to fail. Rather than try to patch up every script call to be invoked
with `$PYTHON` (and regress when non Windows developers forget), copying the
executable into the test binary directory with the new name just works. Since
this directory is prepended to the system PATH value, it also overrides the
broken execution alias. (The `_tmpbindir` is used instead of `_bindir` because
the latter causes python3.exe to be copied into the repo next to hg.exe when
`test-run-tests.t` runs. Something runs with this version of the executable and
subsequent runs of `run-tests.py` inside `test-run-tests.t` try to copy over it
while it is in use, and fail. This avoids the failures and the clutter.)
I didn't conditionalize this on py3 because `python3.exe` needs to be present
(for the shebangs) even when running py2 tests. It shouldn't matter to these
simple scripts, and I think the intention is to make the test runner use py3
always, even if testing a py2 build. For now, still supporting py2 is helping
to clean up the mess that is py3 tests.
[1] https://stackoverflow.com/a/57168165
[2] https://stackoverflow.com/questions/59148628/solved-unable-to-run-python-3-7-on-windows-10-permission-denied#comment104524397_59148666
Differential Revision: https://phab.mercurial-scm.org/D9543
// dagops.rs
//
// Copyright 2019 Georges Racinet <georges.racinet@octobus.net>
//
// This software may be used and distributed according to the terms of the
// GNU General Public License version 2 or any later version.
//! Bindings for the `hg::dagops` module provided by the
//! `hg-core` package.
//!
//! From Python, this will be seen as `mercurial.rustext.dagop`
use crate::{conversion::rev_pyiter_collect, exceptions::GraphError};
use cpython::{PyDict, PyModule, PyObject, PyResult, Python};
use hg::dagops;
use hg::Revision;
use std::collections::HashSet;
use crate::revlog::pyindex_to_graph;
/// Using the the `index`, return heads out of any Python iterable of Revisions
///
/// This is the Rust counterpart for `mercurial.dagop.headrevs`
pub fn headrevs(
py: Python,
index: PyObject,
revs: PyObject,
) -> PyResult<HashSet<Revision>> {
let mut as_set: HashSet<Revision> = rev_pyiter_collect(py, &revs)?;
dagops::retain_heads(&pyindex_to_graph(py, index)?, &mut as_set)
.map_err(|e| GraphError::pynew(py, e))?;
Ok(as_set)
}
/// Create the module, with `__package__` given from parent
pub fn init_module(py: Python, package: &str) -> PyResult<PyModule> {
let dotted_name = &format!("{}.dagop", package);
let m = PyModule::new(py, dotted_name)?;
m.add(py, "__package__", package)?;
m.add(py, "__doc__", "DAG operations - Rust implementation")?;
m.add(
py,
"headrevs",
py_fn!(py, headrevs(index: PyObject, revs: PyObject)),
)?;
let sys = PyModule::import(py, "sys")?;
let sys_modules: PyDict = sys.get(py, "modules")?.extract(py)?;
sys_modules.set_item(py, dotted_name, &m)?;
// Example C code (see pyexpat.c and import.c) will "give away the
// reference", but we won't because it will be consumed once the
// Rust PyObject is dropped.
Ok(m)
}