Summary:
After D15844921, `hg version` is not running the locally built hg.
This command does not provide much useful information, though - we
have a fixed version number and the commit hash is already known
from `hg sl` or other command output.
Therefore remove `hg version`.
Reviewed By: xavierd
Differential Revision: D17097797
fbshipit-source-id: 184a110a1682ee20c973dca7dcc0e2cfd8660976
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
Summary: We want to have just one entry point to Mercurial, namely the Rust binary. Getting rid of the `hg` Python script means that we finally can do things that only exist in Rust and not in Python.
Reviewed By: simpkins
Differential Revision: D13186374
fbshipit-source-id: f3c8cfe4beb7bf764172a8af04fd25202eca9af2
Summary: As a follow-up of D15338757, remove the scripts around building doc/.
Reviewed By: singhsrb
Differential Revision: D15340829
fbshipit-source-id: bc121947696aaecd574edf3d9b9b3e874037bcda
Summary:
This allows us to pass flags to the step building Rust extensions.
For example, `make RFLAG=--debug local` would build extensions in debug mode,
which might take less time.
Reviewed By: singhsrb
Differential Revision: D15204831
fbshipit-source-id: 8906884e6617e20abaabb0d1f2b4e33bb9e304ba
Summary: We don't run this binary anymore, no reason to build and ship it.
Reviewed By: quark-zju
Differential Revision: D14437317
fbshipit-source-id: dd6da521783f18a2a518a7aa042be98950894e89
Summary: Files were moved around and Makefile needs update.
Reviewed By: ikostia
Differential Revision: D14062591
fbshipit-source-id: 5478cf75bc3ff431fc7b24fe7df03e9599c0817f
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
Summary:
Fix final pieces to make IPython work on Windows:
- Install `win_unicode_console`. `pip2 download ipython` running on Linux won't
include it. But running on Windows will.
- Make `build_pyzip` command support `-i`.
- Make `Makefile` run `build_pyzip -i` so IPython.zip gets generated under
mercurial/thirdparty properly.
As we're here, also clean up IPython.zip so it no longer contains `setup.pyc`.
Reviewed By: kulshrax
Differential Revision: D13426947
fbshipit-source-id: 91db6cb85de4c689a4e5c10043debbc26bb94c18
Summary:
Previously we had 2 different places to fetch re2 source code: Makefile and
Windows-only build_nupkg.py. We now have a command in setup.py that fetches them.
Let's just call the "fetch_build_deps" command as part of "build_ext".
This also makes re2 a required component. It's no longer optional.
Reviewed By: DurhamG
Differential Revision: D13352619
fbshipit-source-id: 0bd93560acfbc2e900005a20e4b33a236aad5f98
Summary:
Support pluralized translation strings using ngettext.
This allows strings that are appropriately pluralized based on the count of the
item. To use import `_n` from the `i18n` module and provide it with singular
and plural messages, along with the count of the item that should be pluralized:
```
from mercurial.i18n import _n
ui.write(_n("%d item processed", "%d items processed", count) % count)
```
When using `%`-based string formatting in Python, both variants of the format
string must have the same number of subsitutions: it's not possible to leave
out the `%d` in the singular case.
Reviewed By: quark-zju
Differential Revision: D12921684
fbshipit-source-id: 756d1350a827d0451a07279f6884ee57dba6ac9f
Summary:
Significant chunks of `build_nupkg.py` and `setup.py` are no longer needed.
This diff does a superficial work of cleanign it up.
Reviewed By: phillco
Differential Revision: D10390559
fbshipit-source-id: fc0f03d2e400fe9f400df9b4c1aaf6ba5d498619
Summary:
This relies on adding chef's unix toolchain to the PATH rather than copying stuff from LFS.
Plus, this sets the `HGDEV` env var, which causes `exec\hgmain\src\hgenv.rs` to load
environment from `build\env`. Thus, we don't need to copy `build\hg\hg-python` to the repo dir.
Reviewed By: quark-zju
Differential Revision: D9559617
fbshipit-source-id: de70b262d81befffc651ee82dd5f5e7e0a9c6ed3
Summary:
The `RE2SRC` environment variable needs to be set at both `%build` and
`%install` steps. I didn't notice this issue because `build/re2-...` happened
to exist in my working copy when testing using `make local`.
Reviewed By: markbt
Differential Revision: D9528452
fbshipit-source-id: 1201c5bca06ac6393e518a8adea176cc829c467b
Summary:
If the user provides RE2SRC, do not download re2 from the predefined locations.
In rpmbuild process, the hg subrepo was archived and copied to a nested
subdirectory before the actual building. That means Makefile cannot find lfs.py
correctly and will try to download re2 from GitHub, which would break the build.
However, the rpmspec downloads, extracts, and sets RE2SRC, which should be
respected instead.
Change Makefile to skip downloading re2 if RE2SRC is set to non-default location.
Reviewed By: singhsrb
Differential Revision: D9525885
fbshipit-source-id: 0cbbe7cde61d8d7e8cd79a64fa0231a4089d7ab3
Summary:
This script takes care of the "one-time" setup. So the following things
would work:
- make local
- locally built "hg"
- tests/run-tests.py
Targing Windows (main goal), OSX, and CentOS.
Other scripts or hacks doing similar things are removed.
Reviewed By: phillco
Differential Revision: D9506352
fbshipit-source-id: dbc47e11f6988224c7c2cb59fb36b75ba7f3704b
Summary: This ensures all native components are built so gendoc.py can use them.
Reviewed By: singhsrb
Differential Revision: D9500859
fbshipit-source-id: 64154a5c1ce46abc4792a69aa1ea6d537ef9bdca
Summary:
This causes `make local` to build the new binary, copy the result into the
`.../hg` dir and rename it into `hg.rust` (while `hgmain` seems like a good
crate name, it seems like the binary should be called `hg.rust`, at least for
now)
Reviewed By: quark-zju
Differential Revision: D9218057
fbshipit-source-id: 49a0e09ae78b8cdb64c7158da3bb4179a47d4af9
Summary:
A recent refactor changed the location of the lfs helper, but a number
of paths weren't correct so this broke make local. This fixes them.
Reviewed By: singhsrb
Differential Revision: D8922233
fbshipit-source-id: 90b2997c702aabb352052a410d82554dfa083526
Summary:
We need to tweak users of `lfs` to (a) use if from the new location (b) pass
`-l` if `lfs.py` is used on the command line
Reviewed By: quark-zju
Differential Revision: D8894564
fbshipit-source-id: 652b0b4eba00fd1361f10b41a4c749ad4df7bb5f
Summary:
On OSX developers kept having to set their $PATH or change the make
file to actually build against the homebrew python. Let's build against it by
default if it exists.
Reviewed By: ryanmce
Differential Revision: D7791395
fbshipit-source-id: c69e41a469c5f94825814b4b30bc8ea144112167
Summary:
These stats are hard-coded for now but will in a future diff be fetched from a regularly-updated source.
```
fbclone fbsource --dry-run
usage: fbclone REPO [options]
fbclone: error: fbsource is too large to clone without a sparse profile
Please use one of the following profile switches:
--fbandroid: The full FBAndroid profile, for general development on Android apps.
file count: 644324 (35.83%) size 10.3 GB
--fbcode: The full FBCode profile, for general development on backend code.
file count: 950490 (52.85%) size 14.8 GB
--fbobjc: The full FBObjC profile, for general development on iOS apps.
file count: 620154 (34.48%) size 9.18 GB
--xplat: The base profile for xplat development, separate from other profiles that include xplat
file count: 269858 (15.01%) size 4.41 GB
Or use --everything to get a full-size working copy
```
Differential Revision: D7502448
fbshipit-source-id: e37e4e31d355251e9dd2c390e3de7643fa38b80b
Summary:
There are tests in fb/tests we don't run as part of the test suite. Update the makefile and add buck infrastructure to run them.
- Update the test-common-commands-hg.t test
- Re-generate the fbcode/.hgignore file from the updated .gitignore
Reviewed By: quark-zju
Differential Revision: D7584511
fbshipit-source-id: d85800dccf0eb569a68db4b9e1d9796e3d7ac957
Summary:
Moves the remotefilelog extension into hgext/ and it's tests into
tests/.
I did not fix up all the check-module errors, since it's a ton of work for
very little impact at this point.
Test Plan: make local && ./run-tests.py
Reviewers: #mercurial
Differential Revision: https://phabricator.intern.facebook.com/D6680030
Summary:
cdatapack depends on sha1detectcoll, so let's add the library to setup.py before
we add cdatapack.
Test Plan:
hg purge --all && make local && cd tests/ && ./run-tests.py -S -j 48
Verified sha1dc was in the build output and the tests passed.
Reviewers: quark, #mercurial
Reviewed By: quark
Differential Revision: https://phabricator.intern.facebook.com/D6676405
Signature: 6676405:1515444508:2da65c6c3a18267a1d3c151c8e9acf60b674ffc2
This rule is no longer useful because chg daemon may be killed and respawned
per config/environment hash. We can't reliably run a daemon in foreground.
Before this patch, HGVER would be evaluated at the beginning of the make
execution, and would be unset because build/mercurial/ doesn't exist yet
at that point. Now we compute the version after the `make install` run
has completed.
This is backported to stable from 8626b44516c1, but that revision had an
error in the shell invocation syntax.
The only version strings that are changed are the ones baked into the
.pkg - hg's self-reported version string doesn't change, so users will
still see our mostly-pip-compatible version strings.
For reference, the part of our versioning setup that's not PEP440
compatible is the RC releases - those should be .rc0 insted of
-rc. It's too late to change that for the 4.3 cycle, so I'll worry
about fixing that during the 4.4 cycle.
The way HGVER is evaluated now, it'll be evaluated at the beginning of the
make execution - with this change, it's evaluated when it gets to that command,
at which point the version file it's looking for is sure to exist and be
up-to-date.
Differential Revision: https://phab.mercurial-scm.org/D224
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.
To quote `man 1 pkgbuild`:
--filter filter-expression
By default, --root will include the entire contents of the
given root-path in the package payload, except for any .svn
or CVS directories, and any .DS_Store files. You can override
these default filters by specifying one or more --filter
options. Each filter-expression is an re_format(7)
``extended'' expression: any path in the root which matches
any of the given expressions will be excluded from the pack-
age payload. (Note that specifying even one --filter inhibits
the default filters, so you must respecify the default fil-
ters if you still want them to be used.)
It turns out the default filter these days *also* includes .git and
.hg. Notice how that filter expression is a regular expression? That
(presumably unintentionally) prevents a file named "chg" or "_hg" from
getting included in the distribution. Many many thanks to spectral@
for trying to include a _hg file which led us to figure this bug out.
Bug filed with Apple for this as rdar://problem/32437369, mentioning
both the gap in documentation and the wrong defaults.
Having linux wheels is going to helps system without compiler or python-dev
plus speed up the installation for everyone.
I followed the manylinux example repository
https://github.com/pypa/python-manylinux-demo
to add a make target (build-linux-wheels) using
official docker image to build python 2 linux wheels
for mercurial. It generates Python 2.6 and Python 2.7 for both
32 and 64 bits architectures.
I had to blacklist several test cases for various reasons:
* test-convert-git.t and test-subrepo-git.t because of the git version
* test-patchbomb-tls.t because of warning using tls 1.0
It's likely because the docker image is based on centos 5.0 and
openssl is outdated.
The contrib/zsh_completion file itself says to name it _hg.
With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)`
in their zshrc, it will create a shell function named `hg` that will hide the
actual hg command and make hg unusable.
Separately from that though, the underscore prefix makes it actually work. The
zsh man page states:
The convention for autoloaded functions used in completion is that they
start with an underscore
This does not seem to just be a "convention", though. With the ill-advised line
removed from my zshrc and the file named
`/usr/local/share/zsh/site-functions/hg` (without the underscore), these
completions did not seem to get loaded and the ones from the zsh installation
were loaded instead. If I renamed them to be
`/usr/local/share/zsh/site-functions/_hg`, however, they were loaded.
I manually tested the above statement by starting a new zsh instance with the
file in `/usr/local/share/zsh/site-functions` with the following names:
- As `hg`, `which _hg_labels` did not show anything
- As `_hg`, `which _hg_labels` showed the expected function.