Summary:
It's weird to have `setup_with_versions.py` as the entry point and have noisy
files in the project root. For example, upstream hg has tests to track files
in project root (https://www.mercurial-scm.org/repo/hg/file/c261a628e525/tests/test-check-code.t#l54)
Let's move them back to setup.py.
This is basically a revert of D40983642 (a2eaef5617), followed by:
```
diff --git a/fbcode/eden/scm/setup.py b/fbcode/eden/scm/setup.py
--- a/fbcode/eden/scm/setup.py
+++ b/fbcode/eden/scm/setup.py
@@ -386,9 +386,13 @@
def pickversion():
+ # Respect SAPLING_VERSION set by GitHub workflows.
+ version = os.environ.get("SAPLING_VERSION")
+ if version:
+ return version
# New version system: YYMMDD_HHmmSS_hash
# This is duplicated a bit from build_rpm.py:auto_release_str()
- template = '{sub("([:+-]|\d\d\d\d$)", "",date|isodatesec)} {node|short}'
+ template = r'{sub("([:+-]|\d\d\d\d$)", "",date|isodatesec)} {node|short}'
# if hg is not found, fallback to a fixed version
out = hgtemplate(template) or ""
# Some tools parse this number to figure out if they support this version of
@@ -1829,6 +1833,10 @@
rename=hgname,
features=hgmainfeatures,
cfgs=["Py_%s" % PY_VERSION],
+ env={
+ "SAPLING_VERSION": version,
+ "SAPLING_VERSION_HASH": versionhash,
+ },
),
]
```
The `SAPLING_VERSION` env is only passed to `cargo`. It does not affect the
current process.
This also avoids overhead launching another Python process (previously by
`setup_with_version.py`)
Reviewed By: bolinfest
Differential Revision: D41640370
fbshipit-source-id: 01bd37de7c6dcd1238171c1736137edd82bc07db