re-packaging / providing the stubs

[Josverl]

Moving the conversation here - rather than in a closed Issue

@lukaskremla
I think that taking a copy and basing that off the json (or SQLite data) is much better

two suggestions if you allow :

• uv pip install is much faster, (but it needs to be in place to use it)
• --no-deps, --no-dependencies to create a clean copy,
  but you'll need to handle micropython-stdlib-stubs separately

One request - would it be possible to add a pyproject.toml or requirements-stubs.txt in a project folder ?
that would provide some trackability on public repos who is using which stubs.

[lukaskremla]

Moving the conversation here - rather than in a closed Issue

@lukaskremla I think that taking a copy and basing that off the json (or SQLite data) is much better

two suggestions if you allow :

• uv pip install is much faster, (but it needs to be in place to use it)
• --no-deps, --no-dependencies to create a clean copy,
  but you'll need to handle micropython-stdlib-stubs separately

One request - would it be possible to add a pyproject.toml or requirements-stubs.txt in a project folder ? that would provide some trackability on public repos who is using which stubs.

Thank you for the suggestions! I'm not sure about using --no-deps, since I prefer having self-contained and independent stub packages. However, uv pip seems worth implementing. I'll get to know it a bit and consider implementing it.

About the requirements files. This would be problematic. JetBrains IDEs generally recognize these files and prompt the user to install missing packages listed in them.

Naming the file something that won't match the pattern the IDE looks for could bypass this. However, I don't think the users would appreciate something like this very much.

The IDE creating and modifying the file on its own could be very frustrating. Additionally I'm not aware of a single public repository utilizing this plugin, so this would most likely only annoy users without solving the problem.

I understand why you're looking for solutions like this. The stubs being installed once during the build phase and then distributed as files takes away pip trackability. I would like to help you solve this, but I'd prefer finding a solution that doesn't compromise user experience and that actually solves the problem effectively, since as I said, I don't think there will be very many public repositories using this plugin.

Perhaps a better solution would be not downloading the stub packages during build phase, but rather allowing the user to choose from the available stub packages listed in the json file and then prompting them to install these via a RequirementsInspection pup-up in their IDE. This way you will get to track every individual stub package download and the user experience wouldn't suffer too much. I will have to re-implement python package handling anyway for the planned mpy-cross and mpflash integration

Though I need time to think this through - two main concerns are downloading the package in a way where I can attach it as a python typehint library the way I do currently. The second concern is loosing central control over the stub packages people have installed. You've previously mentioned that the stub packages can appear as having the same name and version, but internally there may be .post1 or .post2 versions. This new approach would have to somehow detect that there's an update in order to prompt the user to download the stubs again.

I'll have to consider this. I'll be implementing mpy-cross and mpflash, so I'll get a better idea of how if at all this could be done soon. Please let me know if this solution would help you.

[Josverl]

Definitely not a requirement, and open to any suggestion you have as well.
Traceability is a nice to have - its a way to keep motivated. Similar as asking asking user to ⭐ a repo.

On the versioning.
I want to keep the Semver ( Major.Minor.Patch) of the stubs the same as the MicroPython version they relate to ,
but on order to be able to ship updates myself , I needed something smaller than a Patch. That is where the Post releases come in. See : Python version Specifiers
The first release will be Major.Minor.Patch.Post1 ( 1.24.1.post1) and any future updates of the stub for that same version of MicroPython will use a ...Postn+1.
so you will always want to install the latest post for a given version. ( critical bugs aside)

If you look at the esp32-stubs version stack you'll see these https://pypi.org/project/micropython-esp32-stubs/#history

I have been contemplating publishing stubs for the pre-releases as well - but I have only occasionally done that.

[lukaskremla]

@Josverl

I noticed that the stub-packages.json wasn't updated with the latest 1.25.0 stubs release. Do you still plan on maintaining this file?

[Josverl]

😱Oops , that is currently a manual action still, and needs some maintenance

If you are looking a file with published stubs , then look in the data folder.
There is a s sqlite and a json version
https://github.com/Josverl/micropython-stubs/blob/main/data/stub-packages.json

[Josverl]

Fixed