view rust/hgcli/README.md @ 51723:9367571fea21

cext: correct the argument handling of `b85encode()`

The type stub indicated that this argument is `Optional`, which implies None is
allowed.  I don't see in the documentation where that's the case for `i`[1], and
trying it in `hg debugshell` resulted in the method failing with a TypeError.  I
guess it was typed as an `int` argument because the `p` format unit wasn't added
until Python 3.3[2].

In any event, 2 clients in core (`pvec` and `obsolete`) call this with no
argument supplied, and `mdiff` calls it with True.  So I guess we've avoided the
None arg case, and when no arg is supplied, it defaults to the 0 initialization
of the `pad` variable in C.  Since the `p` format unit accepts both `int` and
None, as well as `bool`, I'm not bothering to bump the module version- this code
is more permissive than it was, in addition to being more correct.

Interestingly, when I first imported the `cext` and `pure` methods in the same
manner as the previous commit, it dropped the `Optional` part of the argument
type when generating `util.pyi`.  No idea why.

[1] https://docs.python.org/3/c-api/arg.html#numbers
[2] https://docs.python.org/3/c-api/arg.html#other-objects

# Oxidized Mercurial

This project provides a Rust implementation of the Mercurial (`hg`)
version control tool.

Under the hood, the project uses
[PyOxidizer](https://github.com/indygreg/PyOxidizer) to embed a Python
interpreter in a binary built with Rust. At run-time, the Rust `fn main()`
is called and Rust code handles initial process startup. An in-process
Python interpreter is started (if needed) to provide additional
functionality.

# Building

First, acquire and build a copy of PyOxidizer; you probably want to do this in
some directory outside of your clone of Mercurial:

    $ git clone https://github.com/indygreg/PyOxidizer.git
    $ cd PyOxidizer
    $ cargo build --release

Then build this Rust project using the built `pyoxidizer` executable:

    $ /path/to/pyoxidizer/target/release/pyoxidizer build --release

If all goes according to plan, there should be an assembled application
under `build/<arch>/release/app/` with an `hg` executable:

    $ build/x86_64-unknown-linux-gnu/release/app/hg version
    Mercurial Distributed SCM (version 5.3.1+433-f99cd77d53dc+20200331)
    (see https://mercurial-scm.org for more information)

    Copyright (C) 2005-2020 Olivia Mackall and others
    This is free software; see the source for copying conditions. There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# Running Tests

To run tests with a built `hg` executable, you can use the `--with-hg`
argument to `run-tests.py`. But there's a wrinkle: many tests run custom
Python scripts that need to `import` modules provided by Mercurial. Since
these modules are embedded in the produced `hg` executable, a regular
Python interpreter can't access them! To work around this, set `PYTHONPATH`
to the Mercurial source directory. e.g.:

    $ cd /path/to/hg/src/tests
    $ PYTHONPATH=`pwd`/.. python3.9 run-tests.py \
        --with-hg `pwd`/../rust/hgcli/build/x86_64-unknown-linux-gnu/release/app/hg