#stubs version problem

1 messages · Page 1 of 1 (latest)

vocal nebula
#

starting a thread

#

do a make clean before running the stubs making

# 
git checkout 10.0.0-alpha.7
...
HEAD is now at c5128a9902 Merge pull request #10430 from dhalbert/update-frozen-modules-2025-06-17
(venv_cp) root@85594a1475ba:/workspace# python -msetuptools_scm
10.0.0a8.dev0+gc5128a9902.d20250618
#

above is what you had before. That is the correct commit for the 10.0.0-alpha.7 checkout. I wonder if pull --tags was not done properly .... but if so, why is it a8 !?

tough ocean
vocal nebula
#

can we run twine in a "dryrun" mode?

tough ocean
#

I'm guessing the fact that I actually had that change made it view me as in a "dev" version even though I had checked out the alpha7 branch.

vocal nebula
#

if something like that happened in the CI, then the same thing would happen: it looks like a "dirty" build (some change after a commit)

tough ocean
#

I am not sure about twine dryrun, honestly twine is mostly a mystery to me. I've only ever experienced it get used from the actions tasks like ours. I'm not entirely clear on how to troubleshoot issues with it or do anything "manually" to test things out.

#

oooh, I have an idea, let me check the date on something

vocal nebula
#

i don't understand it either. it has "just worked" for me. I am looking at its github issues but nothing come up

tough ocean
vocal nebula
#

there is nothing recent

tough ocean
#

it makes local changes to some files in order to get them to build successfully in latex. Maybe those changes exist and persist during the stubs build that ultimately tries to upload.

vocal nebula
#

This would change the checked in README.rst: mv README.rst.bak README.rst .... yah, I'll bet that is it.

#

those changes are in the local repo clone, and they are present before the stubs are created

tough ocean
#

we could move the latex builds to after the normal stubs build and twine upload

#

in the actions tasks order

vocal nebula
#

I think you should also undo the changes, or maybe we can figure a different way to accomplish your fix.

#

you can just do git restore . on the repo at the end of the latex builds

#

ok, this is the problem. I edited README.rst, and then did make stubs, and I got this:

Successfully built circuitpython_stubs-10.0.0a8.dev0+gc5128a9902.d20250618.tar.gz and circuitpython_stubs-10.0.0a8.dev0+gc5128a9902.d20250618-py3-none-any.whl
#

good thinking on that latex change!!

#

what is the problem with the badge image link? why does latex fall over

tough ocean
#

Ah yeah we could change it back after latex build is complete.

A different solution would be nice, but I could not think of anything better at the time. Our docs include a remotely hosted image (a badge) and the server that hosts it started disallowing non-human traffic. when the latex build runs it tries to download the image but the server returns an error due to automated traffic.

vocal nebula
#

we could copy that badge to our s3 bucket

tough ocean
#

iirc it then tries to include a response error html page as though it is an image and dies(or maybe it's actually the capcha challenge page I don't recall for sure)

tough ocean
vocal nebula
#

oh i see, the badge is dynamic

#

crossed with you

tough ocean
#

if we hosted a static one it won't be able to update. But maybe that is fine given the trouble it's causing.

wanton valve
#

git restore . leaves the README.rst.bak, changing to mv -f would do

vocal nebula
#

if .bak is in .gitignore it might be ok,

#

or use some other suffix like ~

#

not sure that is really the problem....

#

could you try the badge fetch again and see if it fails? Maybe they fixed it.

#

i'm not sure how you can tell if it fails, maybe a curl fetch?

tough ocean
#

it should be possible to test by removing the workaround and trying the latex build.

vocal nebula
#

do we have to do a release, or just do a build?

#

if you submit a PR to revert that merged PR, I guess it will run and we will see!

tough ocean
vocal nebula
#

it is not clear to me which version of pip it is using. says it will start failing in pip 25.3.

wanton valve
#

might not be that, since sysv_ipc succeeds with the same warning ?

vocal nebula
#

is this because we are still using circuitpython-stubs/setup.py instead of a pyproject.toml?

tough ocean
#

I don't think so, but I am not sure.

vocal nebula
#

doesn't have to do with lgpio, i guess

#

i don't even know what that is

#

a blinka-used thing

tough ocean
#

it may be the case that pip install lgpio fails under python 3.13.5

vocal nebula
#

@tough ocean it does fail:

# 
$ pip3 install lgpio
Collecting lgpio
  Downloading lgpio-0.2.2.0.tar.gz (90 kB)
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
  Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: lgpio
  Building wheel for lgpio (pyproject.toml) ... error
  error: subprocess-exited-with-error
  
  × Building wheel for lgpio (pyproject.toml) did not run successfully.
  │ exit code: 1
  ╰─> [8 lines of output]
      running bdist_wheel
      running build
      running build_py
      running build_ext
      building '_lgpio' extension
      swigging lgpio.i to lgpio_wrap.c
      swig -python -o lgpio_wrap.c lgpio.i
      error: command 'swig' failed: No such file or directory
      [end of output]
  
  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for lgpio
Failed to build lgpio
ERROR: Failed to build installable wheels for some pyproject.toml based projects (lgpio)
#

It installs under 3.12 but not 3.13.5. I installed python3.13. Also had to install python3.13-venv to make a venv

#

this is not even with pip 25.3, which isn't out yet? 25.1.1 is latest

wanton valve
#

also lgpio is a linux library apparently, it needs sys_platform == 'linux'

      src/lgpio.h:34:10: fatal error: 'linux/gpio.h' file not found
         34 | #include <linux/gpio.h>
            |          ^~~~~~~~~~~~~~
#

(from what I understand it's used to implement digitalio on Pi)

vocal nebula
#

This did work under 3.12:

$ pip3 install lgpio
Collecting lgpio
  Using cached lgpio-0.2.2.0-cp312-cp312-manylinux_2_34_x86_64.whl.metadata (963 bytes)
Using cached lgpio-0.2.2.0-cp312-cp312-manylinux_2_34_x86_64.whl (372 kB)
Installing collected packages: lgpio
Successfully installed lgpio-0.2.2.0
#

@deep inlet we were not able to pip install lgpio under python 3.13.5. This is used by blinka starting relatively recently?

#

@tough ocean it's getting late here, I think I will stop for now

tough ocean
#

same here, dinner time soon

vocal nebula
#

this is only a problem at the next release, so we can fix this more leisurely

#

unless the rtd problem starts showing up all the time

vocal nebula
tough ocean
#

not attempting to install on mac if it won't ever work makes sense to me, though I don't know what consequence that will have if you are trying to build docs or do anything requiring blinka on mac.

#

for the short term perhaps it's worth changing the docs build containers to use python 3.12.

I was actually somewhat surprised to see that it was on 3.13, when I setup the local container with 24.04 I got 3.12 by default.

When py3.13 starts to become the norm on RPi I assume that lgpio will get an update that fixes it's ability to install under that.

vocal nebula
tough ocean
#

Yeah, the way that library is distributed is kind of... interesting

#

I managed to get it to install by following the build instructions on the download page.

wanton valve
#

I was able to import board digitalio and busio with a MCP2221
and run a script displaying stuff on a SSD1306

tough ocean
#

Nice, thank you for testing.

#

I'm unfamiliar with all of the modifiers in requirements.txt. It might not be possible to limit by specific hardware from it

elfin jetty
tough ocean
#

looks like some target platform_machine I don't know pi5 value for that, but perhaps lgpio just needs a condition like RPi.GPIO and a few others.

tough ocean
#

@elfin jetty I believe your issue about missing swig.exe is tied to this problem ultimately. My understanding is swig is required by lgpio. swig needs to be installed seperately (I think). The fact that it put swig.exe in the error makes me think maybe that exists, but I don't actually know for sure.

In any case lgpio won't really do much for you under windows as I understand it. It was added as a req to Blinka yesterday but we didn't realize the full effects of it at the time.

Ideally we want to get it so that lgpio is not required for installing Blinka on anything except Raspberry pi (or whatever other hardware it supports).

#

I think that the change Neradoc submitted should fix the issue for you.

#

once it's merged and released. I just made the release now. After a few moments it should be propogated to pypi and you can try it again.

elfin jetty
#

The windows stuff was some testing I did afterwards (I didn't know the issue was OS related), my main concern is the Build CI I use (https://github.com/EGJ-Moorington/CircuitPython_Button_Handler/issues/31)

GitHub
workflows-circuitpython-libs/build/action.yml at main · adafruit/w...

A unified build CI for CircuitPython libraries. Contribute to adafruit/workflows-circuitpython-libs development by creating an account on GitHub.

GitHub
Build CI fails when running tests · Issue #31 · EGJ-Moorington/Ci...

As exposed by #30, the Build CI workflow fails when running tests/test_button_handler.py. The error message: ==================================== ERRORS ==================================== _______...

tough ocean
elfin jetty
# tough ocean Ahh, I see. Looking at that now.

The Build CI was working just fine yesterday, so it must be something with either 8.59.0 or 8.60.0, right? From the output log, I can see that it seems to download Adafruit-Blinka just fine, but the fact that it fails on importing it when running pytest made me assume something must be going on with the download as well.

#

Please ping me (either here or on GitHub) if I can help in any way!

tough ocean
#

I replied on github and will put further communication there. It is likely related to the same change in blinka. But I don't think it's quite the exact same issue or resolution as the stubs thing this thread was for.

elfin jetty
wanton valve
#

because adafruit_blinka is not a module, blinka provides board, digitalio, etc.

#

or should it be ?

#

it wasn't in the py modules before 🤔

tough ocean
#

Yeah, I looked in the old setup.py that you linked earlier and it's unclear to me how or why it was working back then. But it seems to me that adafruit_blinka package needs to be included. I submitted a PR adding that to the list in pyproject.toml, but I'm not 100% sure if that is proper solution. And no idea why it didn't need to be listed more explicitly in setup.py

wanton valve
#

seems it might have been implicit in some way ?

tough ocean
wanton valve
#

oh find_packages would be the one doing that on the line above

tough ocean
#

this? packages=find_packages("src") + ["micropython-stubs"],

wanton valve
#

but there is [tool.setuptools.packages.find] ?
ok that requires a deep dive into pyproject.toml

tough ocean
#

yeah, it seems there is some difference in behavior between those

#

pip install adafruit-blinka==8.59.0 results in having all of adafruit_blinka and it's contents in site-packages.

wanton valve
#

could the include list not include what would include adafruit_blinka ? Or do the modules need to be added separately from the packages thing ?

tough ocean
#

8.60.0 results in no adafruit_blinka strangely not even with the microcontroller ones that are specified.

#

unsure if using src for both where and an entry in include would cause a problem. But if not then perhaps that would work

wanton valve
#

yeah, unclear

#

does adding "*" to includes do what the previous behavior was ? It seems to do it 🤔

tough ocean
#

yes, it seems like it to me

elfin jetty
vocal nebula
elfin jetty
tough ocean
vocal nebula
# tough ocean No I don't think so. for the RTD py3.13 issue my understanding is that we have t...

that would fix RTD, but there would still be fundamental problem of trying to use lgpio on any Python 3.13 system, I guess? (e.g. an RPi using 3.13). Seems like something to report to the lgpio folks but I see no way to do that.

Note sure about melissa's comment _This was especially important when the Pi 5 relied on rpi-lgpio (which it no longer does). _ here: https://github.com/adafruit/Adafruit_Blinka/pull/972

#

maybe she means now it depends on lgpio directly?

#

i assume she'll take a look soon

tough ocean
vocal nebula
#

I think it is using a pre-built wheel (?) so maybe that is the problem

tough ocean
vocal nebula
#

which would you choose of 3.12 vs manual build

tough ocean
#

I think using py 3.12. Honestly the idea of wget from a "random" server and make / make install inside of the container kind of sketches me out a little. Perhaps it's unfounded because I assume the bits distributed by pypi could also be problematic in a worst case scenario.

Partially I find it odd how the code isn't super readily available, you could download from pypi and unpackage it to look. But not having the repo in github or any public version control system makes it harder to know what is going on inside of it. And harder to give feedback / research issues with the project as we are finding.

#

given the choice though using py 3.12 and installing automatically with pip feels to me slightly less prone to A) breaking randomly because the server is unavailable or URL changes or whatever and B) having the URL expire or change hands and then start hosting something different, possibly malicious.

#

I assume that at some point py 3.13 will become the norm on RPi and by then this library will get updated to support its install via pip, and at that point we could bump back to 3.13. It is slightly a shame not to be able to just keep using latest, but not the end of the world.

vocal nebula
tough ocean
vocal nebula
#

do you want to make a PR or should I? It's not the first time we've had to hold back Python versions for Reasons.

tough ocean
#

I can make one.