Commit Graph

5 Commits

Author SHA1 Message Date
Jun Wu
484939a75d hgmain: make bindings a builtin module
Summary:
Global states (For example, the global blackbox instance, potentially some
logging / tracing libraries) are separate in the Rust and Python worlds.

That is because related code gets compiled separately:

  bindings.so (top-level)
   \_ blackbox

  hgmain (top-level)
   \_ blackbox (have a different global instance than the above blackbox)

To address it, make `bindings` a builtin module in `hgmain`.

The builtin module was renamed from `edenscmnative.bindings` to `bindings` so
it does not require importing anything else (For example, `edenscmnative`).

This unfortunately makes `hg` 100+ MB. Fortunately it can be compressed well
(gzip: 31MB).

Reviewed By: singhsrb

Differential Revision: D17429688

fbshipit-source-id: bf16910d7a260ca58db0d272fc95d8071d47bbc6
2019-09-20 18:32:36 -07:00
Jun Wu
a17a87bf4f setup: move native extensions to edenscmnative
Summary:
This just moves things around. So native and pure Python modules are split to
different Python packages. This makes it possible to use the standard zip
importer without hacks (ex. `hgdemandimport/embeddedimport`).

This diff is mostly about moving things. While `make local` still works,
it does break nupkg build, which will be fixed in a later diff.

Reviewed By: kulshrax

Differential Revision: D15798642

fbshipit-source-id: 5d83f17099aa198df0acd5b7a99667e2f35fe7b4
2019-06-19 17:55:49 -07:00
Mark Thomas
ae0a81f2c2 rust: move bindings to a single python extension
Summary:
Move all Rust bindings to a single python extension, `bindings`.  This should
improve compilation time and make things simpler.

Reviewed By: quark-zju

Differential Revision: D13923866

fbshipit-source-id: 560592b5a6c0c4f1b836c755ef123666a1059164
2019-02-01 17:53:22 -08:00
Jun Wu
9dc21f8d0b codemod: import from the edenscm package
Summary:
D13853115 adds `edenscm/` to `sys.path` and code still uses `import mercurial`.
That has nasty problems if both `import mercurial` and
`import edenscm.mercurial` are used, because Python would think `mercurial.foo`
and `edenscm.mercurial.foo` are different modules so code like
`try: ... except mercurial.error.Foo: ...`, or `isinstance(x, mercurial.foo.Bar)`
would fail to handle the `edenscm.mercurial` version. There are also some
module-level states (ex. `extensions._extensions`) that would cause trouble if
they have multiple versions in a single process.

Change imports to use the `edenscm` so ideally the `mercurial` is no longer
imported at all. Add checks in extensions.py to catch unexpected extensions
importing modules from the old (wrong) locations when running tests.

Reviewed By: phillco

Differential Revision: D13868981

fbshipit-source-id: f4e2513766957fd81d85407994f7521a08e4de48
2019-01-29 17:25:32 -08:00
Jun Wu
f4fdd7deea zstd: use Rust-backed bindings for its support
Summary:
This allows us to remove the Python binding without breaking existing zstd
users (commitcloud bundles). It might also make the future Rust migration
easier.

Using `zstd` create for its streaming APIs. `zstdelta`'s APIs cannot be used
since it requires decompressed length to be known, which wouldn't work for
streaming compressed data.

Note: For easier implementation, the Python land no longer processes data
in a streaming way. This is probably fine for the current bundle use-case.
In the long term, we might want to revisit the bundle format entirely.

As we're here, also expose zstdelta's APIs and add a test for it.

Reviewed By: DurhamG

Differential Revision: D8342421

fbshipit-source-id: 89902d551f4616469d6e1bc9b334a1c37c884775
2018-06-12 13:22:23 -07:00