mirror
/
micropython
kopia lustrzana https://github.com/micropython/micropython
1
0
Forkuj 0
Kod Zgłoszenia Projekty Wydania Wiki Aktywność
micropython/tools/mpremote/pyproject.toml

54 wiersze
1.5 KiB
TOML
Czysty Zwykły widok Historia

tools/mpremote: Add new CLI utility to interact with remote device. This has been under development since April 2017. See #3034 and #6375. Signed-off-by: Damien George <damien@micropython.org>
2021-05-29 07:12:54 +00:00
[build-system]
requires = [
tools/mpremote: Use hatch to build mpremote package. This allows the entire configuration to be defined in a single file, including the logic for including pyboard.py and automatically versioning based on the git tag. Building the package works both via `python -m build` as well as `hatch build`. `python -m build ` has the advantage of automatically fetching all dependencies, you don't need to manually install any hatch packages. In order to make the versioning work, and also keep things simpler for end users, mpremote releases will now be the same as MicroPython releases and use the same tag. The version strings for mpremote will look like: - X.Y.Z -- clean build at the tag - X.Y.Z.postN+gHASH -- clean build, N revisions from the most recent tag - X.Y.Z.postN+gHASH.dYYYYMMDD -- dirty build, N revisions from out This commit extends on the idea from #8404. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-02-02 13:04:48 +00:00
"hatchling",
"hatch-requirements-txt",
"hatch-vcs",
tools/mpremote: Add new CLI utility to interact with remote device. This has been under development since April 2017. See #3034 and #6375. Signed-off-by: Damien George <damien@micropython.org>
2021-05-29 07:12:54 +00:00
]
tools/mpremote: Use hatch to build mpremote package. This allows the entire configuration to be defined in a single file, including the logic for including pyboard.py and automatically versioning based on the git tag. Building the package works both via `python -m build` as well as `hatch build`. `python -m build ` has the advantage of automatically fetching all dependencies, you don't need to manually install any hatch packages. In order to make the versioning work, and also keep things simpler for end users, mpremote releases will now be the same as MicroPython releases and use the same tag. The version strings for mpremote will look like: - X.Y.Z -- clean build at the tag - X.Y.Z.postN+gHASH -- clean build, N revisions from the most recent tag - X.Y.Z.postN+gHASH.dYYYYMMDD -- dirty build, N revisions from out This commit extends on the idea from #8404. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-02-02 13:04:48 +00:00
build-backend = "hatchling.build"
[project]
name = "mpremote"
description = "Tool for interacting remotely with MicroPython devices"
readme = "README.md"
authors = [
{name = "Damien George", email = "damien@micropython.org"},
]
urls = {Homepage = "https://github.com/micropython/micropython"}
keywords = [
"hardware",
"micropython",
]
license = {text = "MIT"}
classifiers = [
"Intended Audience :: Developers",
"License :: OSI Approved :: MIT License",
"Operating System :: OS Independent",
"Programming Language :: Python :: 3",
"Topic :: Software Development :: Embedded Systems",
"Topic :: System :: Hardware",
]
requires-python = ">=3.4"
dynamic = ["dependencies", "version"]
[project.scripts]
mpremote = "mpremote.main:main"
[tool.hatch.metadata.hooks.requirements_txt]
files = ["requirements.txt"]
all: Switch to new preview build versioning scheme. See https://github.com/micropython/micropython/issues/12127 for details. Previously at the point when a release is made, we update mpconfig.h and set a git tag. i.e. the version increments at the release. Now the version increments immediately after the release. The workflow is: 1. Final commit in the cycle updates mpconfig.h to set (X, Y, 0, 0) (i.e. clear the pre-release state). 2. This commit is tagged "vX.Y.0". 3. First commit for the new cycle updates mpconfig.h to set (X, Y+1, 0, 1) (i.e. increment the minor version, set the pre-release state). 4. This commit is tagged "vX.Y+1.0-preview". The idea is that a nightly build is actually a "preview" of the _next_ release. i.e. any documentation describing the current release may not actually match the nightly build. So we use "preview" as our semver pre-release identifier. Changes in this commit: - Add MICROPY_VERSION_PRERELEASE to mpconfig.h to allow indicating that this is not a release version. - Remove unused MICROPY_VERSION integer. - Append "-preview" to MICROPY_VERSION_STRING when the pre-release state is set. - Update py/makeversionhdr.py to no longer generate MICROPY_GIT_HASH. - Remove the one place MICROPY_GIT_HASH was used (it can use MICROPY_GIT_TAG instead). - Update py/makeversionhdr.py to also understand MICROPY_VERSION_PRERELEASE in mpconfig.h. - Update py/makeversionhdr.py to convert the git-describe output into semver-compatible "X.Y.Z-preview.N.gHASH". - Update autobuild.sh to generate filenames using the new scheme. - Update remove_old_firmware.py to match new scheme. - Update mpremote's pyproject.toml to handle the "-preview" suffix in the tag. setuptools_scm maps to this "rc0" to match PEP440. - Fix docs heading where it incorrectly said "vvX.Y.Z" for release docs. This work was funded through GitHub Sponsors. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-10-04 00:20:47 +00:00
# This will be PEP-440 normalised into either:
# mpremote-X.Y.Z (on vX.Y.Z release tag)
# mpremote-X.Y.Zrc0 (on vX.Y.Z-preview tag, i.e. first commit in the cycle)
# mpremote-X.Y.Zrc0.postN+gHASH (N commits past vX.Y.Z-preview tag)
# mpremote-X.Y.Zrc0.postN+gHASH.dDATE (N commits past vX.Y.Z-preview tag, dirty)
tools/mpremote: Use hatch to build mpremote package. This allows the entire configuration to be defined in a single file, including the logic for including pyboard.py and automatically versioning based on the git tag. Building the package works both via `python -m build` as well as `hatch build`. `python -m build ` has the advantage of automatically fetching all dependencies, you don't need to manually install any hatch packages. In order to make the versioning work, and also keep things simpler for end users, mpremote releases will now be the same as MicroPython releases and use the same tag. The version strings for mpremote will look like: - X.Y.Z -- clean build at the tag - X.Y.Z.postN+gHASH -- clean build, N revisions from the most recent tag - X.Y.Z.postN+gHASH.dYYYYMMDD -- dirty build, N revisions from out This commit extends on the idea from #8404. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-02-02 13:04:48 +00:00
[tool.hatch.version]
source = "vcs"
all: Switch to new preview build versioning scheme. See https://github.com/micropython/micropython/issues/12127 for details. Previously at the point when a release is made, we update mpconfig.h and set a git tag. i.e. the version increments at the release. Now the version increments immediately after the release. The workflow is: 1. Final commit in the cycle updates mpconfig.h to set (X, Y, 0, 0) (i.e. clear the pre-release state). 2. This commit is tagged "vX.Y.0". 3. First commit for the new cycle updates mpconfig.h to set (X, Y+1, 0, 1) (i.e. increment the minor version, set the pre-release state). 4. This commit is tagged "vX.Y+1.0-preview". The idea is that a nightly build is actually a "preview" of the _next_ release. i.e. any documentation describing the current release may not actually match the nightly build. So we use "preview" as our semver pre-release identifier. Changes in this commit: - Add MICROPY_VERSION_PRERELEASE to mpconfig.h to allow indicating that this is not a release version. - Remove unused MICROPY_VERSION integer. - Append "-preview" to MICROPY_VERSION_STRING when the pre-release state is set. - Update py/makeversionhdr.py to no longer generate MICROPY_GIT_HASH. - Remove the one place MICROPY_GIT_HASH was used (it can use MICROPY_GIT_TAG instead). - Update py/makeversionhdr.py to also understand MICROPY_VERSION_PRERELEASE in mpconfig.h. - Update py/makeversionhdr.py to convert the git-describe output into semver-compatible "X.Y.Z-preview.N.gHASH". - Update autobuild.sh to generate filenames using the new scheme. - Update remove_old_firmware.py to match new scheme. - Update mpremote's pyproject.toml to handle the "-preview" suffix in the tag. setuptools_scm maps to this "rc0" to match PEP440. - Fix docs heading where it incorrectly said "vvX.Y.Z" for release docs. This work was funded through GitHub Sponsors. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-10-04 00:20:47 +00:00
tag-pattern = "(?P<version>v(\\d+).(\\d+).(\\d+)(-preview)?)"
tools/mpremote: Use hatch to build mpremote package. This allows the entire configuration to be defined in a single file, including the logic for including pyboard.py and automatically versioning based on the git tag. Building the package works both via `python -m build` as well as `hatch build`. `python -m build ` has the advantage of automatically fetching all dependencies, you don't need to manually install any hatch packages. In order to make the versioning work, and also keep things simpler for end users, mpremote releases will now be the same as MicroPython releases and use the same tag. The version strings for mpremote will look like: - X.Y.Z -- clean build at the tag - X.Y.Z.postN+gHASH -- clean build, N revisions from the most recent tag - X.Y.Z.postN+gHASH.dYYYYMMDD -- dirty build, N revisions from out This commit extends on the idea from #8404. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
2023-02-02 13:04:48 +00:00
raw-options = { root = "../..", version_scheme = "post-release" }
[tool.hatch.build]
packages = ["mpremote"]
[tool.hatch.build.targets.sdist.force-include]
"requirements.txt" = "requirements.txt"