RFC: URL/package.json support in frozen module manifests
Description
manifest.py files currently support installing from micropython-lib with require(); I propose extending the syntax to match that of mip, namely by adding support for a package.json hosted elsewhere (URL, GitHub, or GitLab) and individual .py files by URL.
My initial implementation thoughts are:
- Allow
github:,gitlab:, andhttp://links to be passed torequire()in addition to normal package names - Add an optional
version=<x>keyword argument to match themip.install()interface - Port the existing
mipfunctionality either from the module or from mpremote to download modules to a local cache directory during manifest processing - Add these downloaded files to the
ManifestFiledatabase so they can be frozen into the firmware with the existing manifest machinery
Please let me know if you have any thoughts/comments/suggestions.
Justification: I'm currently working on a project that uses a number of external libraries I freeze into firmware. I'm using git submodules to pull in library dependencies within the project and package()/modules() to include these into the firmware, however:
- I anticipate expanding to multiple firmware variations, which may use different sets of libraries; it may become tedious to set up all required submodules and fetch the correct ones for the firmware being built
- This doesn't provide support for freezing a single
.pyfile (unlikemip) from a repository without cloning the entire repository. For example, I'd like to include thetyping.mpyfile in my firmware for the libraries I use, but I would rather not include the entire repository for it as a submodule.
Code Size
No response
Implementation
I intend to implement this feature and would submit a Pull Request if desirable
Code of Conduct
Yes, I agree
bisect, json, keyword, types: Add manifest.py.
Add manifest files for bisect, json, keyword, and types since they appeared to have been overlooked.
I ran into trouble when trying to compile Pi Pico firmware with keyword as a frozen module after which I found several other modules without manifests. Adding the manifest for keyword resolved my compilation issue, so I have assumed that the other manifests are functional as well.
It wasn't readily apparent what the versions of each of these modules are, so I chose not to add anything about that to their metadata. (It's also a little unclear to me what the version is meant to represent -- version of the Python stdlib that it's ported from or the version of the port itself or is it up to the author?).
Thanks for the contribution, and sorry that this PR got lost/overlooked.
What you did in this PR is correct.
But it was done also by someone else and merged in commits c2b44ea83b1cb930e91ddc1f81ffb426846acdd0, 0f768c9af71b69b5f4e81f0cab8aaa403c820c2e, b95deb31e51c017fd62971fb7c2a050a70be1ba3, 028a369f903fa395e8ed57dcaf8fba98f684cecc