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
Summary:
In the future the changelog would need to access 'remotenames' to figure out
public heads. Move the state file to svfs so it can be read by the changelog
object, which only has access to svfs.
Reviewed By: sfilipco
Differential Revision: D17199834
fbshipit-source-id: 9000e0d8e8bb8d398d6c77b5b395da904fef6418
Summary: This makes IPython work without disabling demandimport.
Reviewed By: xavierd
Differential Revision: D16509106
fbshipit-source-id: d4443d8b58c90a0fd7a34c620756e88f4f788337
Summary:
Add more shortcuts to common modules.
This make it easier to test changed code paths.
Reviewed By: markbt
Differential Revision: D15952263
fbshipit-source-id: c0eca6a61902d36a26a99f85e29dc70f431eca59
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
Summary:
Move top-level Python packages `mercurial`, `hgext` and `hgdemandimport` to
a new top-level package `edenscm`. This allows the Python packages provided by
the upstream Mercurial to be installed side-by-side.
To maintain compatibility, `edenscm/` gets added to `sys.path` in
`mercurial/__init__.py`.
Reviewed By: phillco, ikostia
Differential Revision: D13853115
fbshipit-source-id: b296b0673dc54c61ef6a591ebc687057ff53b22e