Python targets in this repository import one another under the
"tflite_micro" package namespace, which //:tflite_micro_shim synthesizes
at import time. The shim is required under Bzlmod, where the main
repository's runfiles root is the fixed name "_main" rather than the
module name, so the "tflite_micro" prefix no longer resolves on its own.
Every such target therefore had to list //:tflite_micro_shim in its
deps, which was repetitive and easy to forget.
Add tflm_py_library, tflm_py_test, and tflm_py_binary wrappers in a new
//python:py_rules.bzl that inject the shim dependency automatically,
following the naming convention of the existing tflm_cc_* wrappers, and
document the shim's rationale there. Convert every target that
previously listed the shim to the corresponding wrapper and drop the
explicit dependency. The dependency graph is unchanged; only the means
by which the shim is attached differs.
Use Bazel's workspace status mechanism, designed for "stamping" builds with
identifying information from the build environment, to dynamically generate the
version label of the Python distribution package. Generate stamps when Bazel
runs via the --workspace_status_command option and command script. Then use
these stamps in the version label.
Guidelines for Python version labels are given in [PEP 440][]. TFLM does not
currently tag and publish what PEP 440 calls "final releases". Instead,
distribution packages will periodically be published from the tip of the main
branch, and users will be expected to use the latest version or pin to a
historical version of their choice. To facilitate such use, the build system
needs to generate a unique, ascending version label for each commit on the main
branch.
Guided by [PEP 440][], use developmental version labels of the form
*major[.minor].dev<time>*, for example:
0.dev20090103181505
Use a release segment with a major number of 0 (via the standard Bazel
BUILD_EMBED_LABEL stamp), because TFLM does not currently tag and publish
releases. This leaves room in the version space for making semver-style final
releases in the future. Add a developmental release segment with a date and
time stamp.
Packages should be traceable to the exact source from which they were built.
[PEP 440][] does not allow Git hashes in version labels published to PyPI;
however, the Git hash can be embedded in the package's runtime-visible
attribute `tflite_micro.__version__`, and in the package's description, which
is displayed on PyPI.
[PEP 440]: https://peps.python.org/pep-0440
BUG=part of #1484
