sapling/exec/hgmain/Cargo.toml
Jun Wu 8997f2f15d windows: switch to the new Python runtime
Summary:
Switch to the new Python runtime. Remove parts that are incompatible and no
longer necessary, including:

- Building curses, python-lz4, and urllib3 (in build_nupkg.py).
- Mangling sys.path (in hgpython and entrypoint.py).
- Zip-related logic (in hgpython).
- Cargo features controlling build environment (in hgpython and hgmain).
- Zipping Python stdlib (in setup.py).
- Shipping files in `templates`, `help`, and most `contrib` files (in
  setup.py).

For the hgpython part, the new expectation is: in all cases (windows, linux,
make local, installed, buck), `edenscm.mercurial.entrypoint` and
`edenscmnative` modules are always directly importable and are always the
expected modules if imported. So the `hg` logic just imports and runs it
without having any `sys.path` related logic.

To explain it further:
- When installed on a POSIX system, the default `sys.path` contains
  site-packages.  Both edenscm and edenscmnative are in site-packages.
- When installed on Windows, the executable (hg.real.exe), python27.dll,
  python27.zip, and edenscmnative/ are all in a same directory. Therefore the
  default sys.path (exe dir + python27.zip) would be sufficient.
- When using `make local`, and run via `scm/hg/hg`, the `PySys_SetArgv` API
  (called by `hgpython`) inserts the `scm/hg` directory as `sys.path[0]`,
  therefore edenscm and edenscmnative in `scm/hg` will be imported as expected.

Since we no longer hard code paths to search for modules, this should fix
issues on systems with a different sys.path, ex. debian and ubuntu uses
"dist-packages" instead of "site-packages".

Note: IPython is broken. It seems to be a combination of newer Python version,
newer compiler and 64 bit (see [1]). It looks like prompt_toolkit incorrectly
uses untyped ctypes APIs where it passes "int/long"s to places expecting a
HANDLE. The ctypes library uses 4-byte integers for plain "int/long"s where a
HANDLE is 8 byte on 64 bit Windows.  The new interpreter is stricter somehow
and will error out in this case (also explains why D15912516 is needed).

The fix to prompt_toolkit was sent as
https://github.com/prompt-toolkit/python-prompt-toolkit/pull/930.

[1]: https://github.com/prompt-toolkit/python-prompt-toolkit/issues/406

Reviewed By: ikostia

Differential Revision: D15894694

fbshipit-source-id: 560d11ae28c1e65d58b760eac93701e753bd397e
2019-06-24 08:34:23 -07:00

25 lines
416 B
TOML

[package]
name = "hgmain"
version = "0.1.0"
edition = "2018"
build = "build.rs"
[dependencies]
libc = "0.2"
dirs = "1.0"
[target.'cfg(windows)'.dependencies]
winapi = {version = "0.3.7", features = ["handleapi", "processenv", "winbase"]}
failure = "0.1"
[dependencies.encoding]
path = "../../lib/encoding"
[dependencies.hgpython]
path = "../../lib/hgpython"
[features]
buildinfo = []
default = []
with_chg = []