sapling/eden/scm/packaging/windows
Jun Wu 8306d233c3 setup: merge setup*.py back to setup.py
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
2022-12-01 12:30:00 -08:00
..
build_windows_zip.py setup: merge setup*.py back to setup.py 2022-12-01 12:30:00 -08:00