mpremote: Use hatch to build mpremote package. #10645
Conversation
|
Code size report: |
|
Also adds a |
|
Another note: I investigated using |
|
Could also consider moving mpremote and its dependant scripts to a submodule for a much cleaner package design and ease of tag/release... |
Honestly there was a point when I was trying to get setuptools to work where I considered this, but you still have the same problem with pyboard.py living in main-repo/tools. And the |
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 micropython#8404. Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
1203076 to
59e061d
Compare
|
Thanks for this, it's a good improvement.
Yes I think this is the best and simplest solution, and will reduce confusion for users, to just have mpremote and MicroPython versioned the same. I tested this and it works, although we will need to now always have a revision number in the version, eg |
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
59e061d to
7c6a985
Compare
|
I tuned the github workflow to only run on a pull request if tools/ files change (but it still runs unconditionally on a normal push to master). |
Extending on the idea from #8404 (@andrewleech ) the idea is to use as little custom code as possible and use standard tools (i.e.
hatch) from the Python packaging ecosystem to:Also includes the GitHub workflow from #8404 to build the wheel. Increased the fetch depth to 1000 (we're currently 850 commits from 1.19.1 !!!)
This works both via
python -m build(this is what the workflow uses) as well ashatch build.python -m buildhas the advantage of automatically fetching all dependencies, you don't need to manually install any hatch packages.In order to make the versioning work, we need to add mpremote tags to this repo. I suggest adding for example
mpremote-v0.4.0, which can be matched by thetag-patternregular expression. Right now it matches the MicroPython version instead (e.g. v1.19.1). Alternatively, we could pin the mpremote releases to the MicroPython releases and use the same tags?The version strings look like:
X.Y.Z-- Clean build at the tagX.Y.Z.postN+gHASH-- Clean build, N revisions from the most recent tagX.Y.Z.postN+gHASH.dYYYYMMDD-- Dirty build, N revisions from the most recent tag