Build pipeline

44 views
Skip to first unread message

Olivier Bélanger

unread,
May 25, 2026, 8:19:13 AM (13 days ago) May 25
to pyo-d...@googlegroups.com
Hello,

Starting a new thread on that subject...

"
I fixed up the build pipeline and crated a new PR hopefully this time in the org repo . 
https://github.com/pyo-org/pyo/pull/2
I tested this using actions and it builds windows , mac and ubuntu versions of pyo targeting a few different python versions up to 3.13 
I think the next step might be to publish these wheel directly to pypi. 
take a look . 
Sean
"

Thanks Sean for putting that pipeline in place, it's greatly appreciated! That will ease the process of releasing a new version in the future a lot.
 
A couple of concerns here...

1. Have those wheels been tested?
2. Do they package third-party libs correctly?
3. What about Mac code sign, and microphone access?
4. Once a release has been published on pypi.org, we can't replace the files or re-use that version... We should really upload the wheels on test.pypi first, and when we have confirmation that they are ok, then we publish on pypi. That's why I wanted to use even version numbers as "testing", and odd ones as "release". I could be another scheme if someone has a better idea!
5. Python 3.9 has officially reached end-of-life... I suggest releasing for 3.10 to 3.14.
6. I think the manylinux wheels are a nice thing to have, but the management of alsa and jack libs are very clunky (literally buggy) with those wheels... I should try to give it another shot...

Last thing, the Python C API has changed a lot around 3.9-3.10, and now there are a lot of memory leaks from pyo's initialization... I'd like to fix that before the next release.

Thanks again for that work (great quality-of-life improvement),

Olivier

Sean Wayland

unread,
May 25, 2026, 10:17:25 AM (13 days ago) May 25
to pyo-d...@googlegroups.com
On Mon, May 25, 2026 at 8:19 AM Olivier Bélanger <bela...@gmail.com> wrote:
Hello,

Starting a new thread on that subject...

"
I fixed up the build pipeline and crated a new PR hopefully this time in the org repo . 
https://github.com/pyo-org/pyo/pull/2
I tested this using actions and it builds windows , mac and ubuntu versions of pyo targeting a few different python versions up to 3.13 
I think the next step might be to publish these wheel directly to pypi. 
take a look . 
Sean
"

Thanks Sean for putting that pipeline in place, it's greatly appreciated! That will ease the process of releasing a new version in the future a lot.
 
A couple of concerns here...

1. Have those wheels been tested?
Not at all ! I wonder if some sort of integration testing can be built into a pipeline .  
2. Do they package third-party libs correctly?
I have no idea. I battled with claude for quite some time to get it to build across all the different versions. 
At one point I suggested that claude "monkey patch setup.py ". 
I wondered if a build script or make files was needed perhaps setup.py is enough perhaps it can be improved .
I just battled with claude till it got the wheels to build inside github.  
3. What about Mac code sign, and microphone access?
That's a good question and probably needs to be added.  
4. Once a release has been published on pypi.org, we can't replace the files or re-use that version... We should really upload the wheels on test.pypi first, and when we have confirmation that they are ok, then we publish on pypi. That's why I wanted to use even version numbers as "testing", and odd ones as "release". I could be another scheme if someone has a better idea!
 I asked the oracle : 
"On PyPI, “beta” releases are just normal package uploads that use a pre-release version number defined by PEP 440, such as 1.0.0b1 or 2.0.0rc1. You publish them the same way as any release, but tools like pip ignore these versions by default unless the user explicitly opts in (e.g., with pip install --pre) or no stable version exists. Many developers also test these pre-releases first on TestPyPI before uploading to the main Python Package Index, which helps catch issues without exposing them to the broader user base, and then later release a final version like 1.0.0 once it’s ready."
One way to do this might be to use git tags and tag merge commits or builds somehow.
Solving that seems easy it's the integration testing that is the tricky part I will think a bit more about it. 
Perhaps we are still stuck with "real people testing wheels". 
I do have all the operating systems lying around could possibly do that and it's probably the only sane way to do it that's what I would do at work. 
Would never "release" a binary that hadn't had some real testing I think in software development especially with claude involved now its the ONLY thing that really counts. "does it work" 
5. Python 3.9 has officially reached end-of-life... I suggest releasing for 3.10 to 3.14.
Good idea .  
6. I think the manylinux wheels are a nice thing to have, but the management of alsa and jack libs are very clunky (literally buggy) with those wheels... I should try to give it another shot...
Perhaps Linux people are more inclined to just "build from sources". I looked at the readme and scripts. 
There are not specific "linux build" instructions in the readme. 

Last thing, the Python C API has changed a lot around 3.9-3.10, and now there are a lot of memory leaks from pyo's initialization... I'd like to fix that before the next release.
Yep I have enough "leaky" applications already :) I am in no hurry ! 

Thanks again for that work (great quality-of-life improvement),

Olivier

--
You received this message because you are subscribed to the Google Groups "pyo-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pyo-discuss/CAMXBGhRGdY98OpxnhU2UmL4NSd4qXJHSWN-gJeX-YxTwt1pTuA%40mail.gmail.com.


--


http://seanwayland.com

https://github.com/seanwayland



Sean Wayland           

US cell phone: +1 (347)5231455


Sean Wayland

unread,
May 25, 2026, 10:41:19 AM (13 days ago) May 25
to pyo-d...@googlegroups.com
further to this . 
this commit will keep the wheels around as artififacts on github for testing. 
I believe they will live for 90 days. 
https://github.com/pyo-org/pyo/compare/e433221d733d599d3c2b91d00980f594f7e7db16..4dca6b9dfd413eb0bb2e2c2185b13e32f51c4324
I also did another commit removing python 3.9 
It is trying to publish to test pypi but failing which is probably fine for now. 
I see some build artifacts here at the bottom. 
https://github.com/pyo-org/pyo/actions/runs/26405465182


Sean Wayland

unread,
May 25, 2026, 12:38:47 PM (13 days ago) May 25
to pyo-d...@googlegroups.com
even more : 
I tried testing one of the mac OS wheels py ver 3.13 . It complained about the os version named in the file. I am on 10.13 and the wheel said 10.15 
I renamed the wheel and it worked . 
I made a further commit targeting OSX 10.13 in the build pipeline. 
We could support an earlier OSX version I think the lowest version we want to support needs to be put into the CICD script. 
This test script made a note after pin installing using the wheel on mac osx 3.13 

```
#!/usr/bin/env python
"""
Simple pyo test script: Generate a sine wave without audio playback
(Works in CI/headless environments)
"""
import pyo
import time

def test_sine_wave_generation():
"""Generate and analyze a sine wave"""
print("Testing pyo sine wave generation...")
# Create server in no-soundcard mode
s = pyo.Server(duplex=False)
s.setOutputDevice(-1) # -1 = no audio device
try:
s.boot()
s.start()
print("✓ Audio server started (no-soundcard mode)")
# Create a simple sine wave at 440 Hz (A4 note)
print("Creating 440 Hz sine wave...")
sine = pyo.Sine(freq=440, mul=0.1) # 0.1 = volume (10%)
# Create a table to record the sine wave
table = pyo.NewTable(length=0.1) # 100ms table
sine.out(chnl=0)
# Use TableRec to record the sine wave
rec = pyo.TableRec(sine, table=table).play()
print("✓ Sine wave object created")
print("Recording sine wave to table...")
time.sleep(0.2) # Record for 200ms
rec.stop()
print("✓ Recording complete")
# Verify the table has data
data = table.getTable()
print(f"✓ Generated {len(data)} samples")
print(f" Min value: {min(data):.4f}")
print(f" Max value: {max(data):.4f}")
# Check it looks like a sine wave
if abs(max(data)) > 0.08 and abs(min(data)) < -0.08:
print("✓ Wave amplitude looks correct (~0.1)")
print("\n✓ Test completed successfully!")
return True
except Exception as e:
print(f"✗ Error: {e}")
import traceback
traceback.print_exc()
return False
finally:
print("Shutting down audio server...")
s.stop()
s.shutdown()
print("✓ Done")

if __name__ == "__main__":
success = test_sine_wave_generation()
exit(0 if success else 1)
```

Aaron Krister Johnson

unread,
May 26, 2026, 4:28:45 PM (12 days ago) May 26
to pyo-d...@googlegroups.com
Please, let's also format all python code moving forward using `ruff format`. I can make a commit to get that into place in CI.

For instance, Sean, your test sine-wave example should have 2 blank lines between function declarations, etc. etc. It seems unimportant but consistent formatting gives
a very nice clean consistency to a codebase, and allows folks to precisely focus on the logic of the code, rather than its look (or disagreeing on how it should look).



Sean Wayland

unread,
May 26, 2026, 4:51:03 PM (12 days ago) May 26
to pyo-d...@googlegroups.com
Thats a good idea.
That test code wasnt committed. Trying to sanity check the builds more of that needs to be done. 
If I put ruff into the github actions pipeline do you want it format or fail the pipeline with linting errors ?



http://seanwayland.com

https://github.com/seanwayland



Sean Wayland           

US cell phone: +1 (347)5231455


Aaron Krister Johnson

unread,
May 26, 2026, 5:20:53 PM (12 days ago) May 26
to pyo-d...@googlegroups.com

Olivier Bélanger

unread,
May 26, 2026, 5:24:56 PM (12 days ago) May 26
to pyo-d...@googlegroups.com
I also agree on the code formatting! Failing the build, I don’t know… To be discussed!

About the sine example, Sean, it’s very nice, and I think we should have more… I have a couple of comments and cues about this, but on my cell right now… I’ll get back to you later!

Olivier

Alexandros Drymonitis

unread,
Jun 1, 2026, 1:07:15 PM (6 days ago) Jun 1
to pyo-discuss
Where are we on this? Olivier, when you write that we should have more, what do you mean? Can I be of any help?
Pyo now depends on the free time of more than one people, but it can still get stuck and forgotten as our attention shifts towards everyday responsibilities. So, I'm pocking this thread to see if we can move forward and get 1.0.7 out.

Aaron Krister Johnson

unread,
Jun 1, 2026, 2:32:10 PM (6 days ago) Jun 1
to pyo-d...@googlegroups.com
Alexandros, I think when Olivier said "we should have more" he meant "It would be nice to have more examples like Sean's sine example".

I don't think he meant that there was a blocker on the testing of 1.0.7 or anything like that?

Alexandros Drymonitis

unread,
Jun 1, 2026, 2:36:31 PM (6 days ago) Jun 1
to pyo-d...@googlegroups.com

That's what I thought, but then, if a sine wave works, why are more tests needed, and what kind of tests are needed? I didn't think he meant anything is blocking the next release. It's just that a week passed and I thought of pocking the team to see where we're at. Also, to see if I can chip in with more examples, inspired by Saen's sine example.

Sean Wayland

unread,
Jun 1, 2026, 6:26:36 PM (6 days ago) Jun 1
to pyo-d...@googlegroups.com
Hi all,
I was hoping to test that build pipeline a bit. Kinda out of time right now. I think you could just merge it in it is pretty harmless I think. 
When I have a bit more time I will think a bit more about improving it. Seems pretty useful to have it just run and complain if it cant build a version for you. 
The "test" script was just a quick attempt to verify the pipeline on my own OS . It passed ! 
Sean


Olivier Bélanger

unread,
Jun 1, 2026, 9:40:36 PM (5 days ago) Jun 1
to pyo-d...@googlegroups.com
Hi,

What I had in mind is an integration suite testing the DSP performed by every object, validating against know-to-be-good reference. The unit tests in the repo only validate the common operations like arithmetic operations, comparison, adding/removing objects, etc., but the DSP library itself remains untested (we just trust that everything is still ok). There is a very long road before having each object truly tested, but with a build pipeline, it begins to make sense... Food for thought! 

One thing I wanted to pinpoint is the Server's "manual" mode (audio="manual"), it completely bypasses the audio backend callback, and we can manually advance the server's process loop one buffer at a time. Useful to build integration test suites!

Finally, I am halfway through PEP 489, multi-phase initialization is done, I'd like to give a shot at multiple sub-interpreters support before 1.0.7 (there are still some global static variables that are unsafe in multiple sub-interpreters context). Should be done soon...

Olivier
  

On Mon, Jun 1, 2026 at 2:36 PM Alexandros Drymonitis <alexdry...@gmail.com> wrote:

Aaron Krister Johnson

unread,
Jun 2, 2026, 3:54:46 PM (5 days ago) Jun 2
to pyo-d...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages