Alright, I’ll take a look 
Just to clarify:
No issue with people using the Python 3.11.x version we have on the repos, as long as people are happy to rely only on pip3.11 to install the packages they need (as opposed to using pkgman install), as at least I don’t plan to work on adding “_python311” .hpkg files (except for pip_python311 / setuptools_python311 to get pip3.11 usable).
Reason for this is… trying to avoid having to maintain packages for too many different Python versions at the same time (we had up to 5 previously), specially with the changes around Python 3.12 , and packages moving away from distutils/setuptools into “more modern packaging” tools.
I think that for Haiku-PyAPI, we could very well add a _python311 .hpkg if needed/wanted, even if just for convenience/testing, once the time comes.
In any case… Happy to receive reports/suggestions regarding any of the Python recipes we have, so we can try to make them better.
2 Likes
Now you can specify which Python version you want to build using -spython_version or -spy 
. The first form would go into recipes so that people reading it understand what is meant by it and the second form can be used from the terminal to reduce typing.
Some miscellaneous thoughts:
Now I understand why you keep making folders called Be. Because you want to write from Be import * in Python.
Should we keep our Jamfile as commented as it is now or should we reduce their number? (I can do this as a pull request so that you can provide feedback on the final result.)
I’m getting tempted to rename the bin folder to generated since, now, that’s all it’s holding, and, that’s what it’s called on Haiku.
2 Likes
I managed to create a .hpkg out of Haiku-PyAPI .
Now I’m wondering when should I publish the recipe? Now, or when we have some kind of release?
6 Likes
While I’m far from being an expert in Python packaging, I think it would be good to investigate the possibility of having these bindings build into a wheel (.whl) distribution targetting abi3 (instead of having to compile them for each different Python version). Assuming this is possible at all, of course, I’ve no idea about pybind11 usage/requirements.
Assuming that’s possible, the resulting .whl file could be used either via pip install (outside of HaikuPorts), or from our recipes (via python -m installer filename,whl) to create python-version specific .hpkg files.
Mmm, docs around usage of abi3 wheels seems to be “sub-optimal” (or I just failed to find the good stuff). So maybe using “one wheel to rule them all” might be just a long term goal? .
Some links:
https://docs.python.org/3/c-api/stable.html#limited-c-api
https://blog.trailofbits.com/2022/11/15/python-wheels-abi-abi3audit/
2 Likes
If it is at least half way usable, then I’d say now. This way you probably get more people to try out the new binding, experiment with them and hopefully report back bugs and missing stuff.
And do you think I should put it on Haikuports?
I can update Haiku-PyAPI multiple times a day,
it would be tedious to send a PR each time I update it.
I think it would be better if I could host it on PyPi, which doesn’t require approval.
@Zardshard we can publish it when we have some kind of beta release,
until then we can host it on PyPI and/or have hpkgs in the github releases.
We need a goal, or some sort of checklist for the release, so we know when we are ready.
Thanks for the lead! Not looking too promising right now since pybind’s docs only mention linking to the current version of python, but I’ll want to look further into it.
What about when the app and interface kit are done?
2 Likes
The app kit is already ‘done’, although new ways may be found to fix commented-out sections, and the whole interface kit is a goal for 1.0, not 0.1.
Maybe have a list of essential widgets?
We have text boxes, buttons, text, and windows to put them in. I suppose those are all of the essential widgets.
Then I suppose now is the time for 0.1.
2 Likes
The 0.1 release is done! You can now install haiku_pyapi_python39 and haiku_pyapi_python310 from HaikuDepot.
11 Likes
I’ve tried targeting abi3 (by adding -DPy_LIMITED_API=0x030900 to SubDirC++Flags on the Jamfile, but sadly, that’s a no go, as pybind11 seems to use/need plenty of stuff outside of what’s available when Py_LIMITED_API is defined. Oh well… was worth a try .
BTW, when trying that define, the build seemed to enter a loop, and was kinda hard to kill all the jam related processes.
On the plus side… got PyAPI working on 32 bits (haiku_pyapi_x86_python310). Created a PR for the needed changes on Haiku-PyAPI’s side (the recipe changes will have to wait for a 0.2 release 
).
3 Likes
This actually seems like it’s possible, see an example of how to register plugins using decorators for an idea of how this would be done.
The main issue I could see would be the lifespan, ownership and construction time of the BMessage object.
Yes. For some functions, I think you want to copy into a new BMessage. Constructors for subclasses of Invoker, at least. Probably others.
I talked with @coolcoder613 over IRC about this. The trouble is that the function decorators don’t have access to the class’s members. This is because the decorators don’t take a parameter for self.
If you would like to know more, you can visit Python decorators in classes.
A Haiku about a Python API:
App, Support, Storage,
And all the rest, for Python
Now available!
I think it’s about time I start working on releasing v0.2, since the app kit is pretty much done.
11 Likes
We’re encountering some errors when compiling for R1/B4 and not when compiling on a nightly. One commit that is causing these discrepancies is https://git.haiku-os.org/haiku/commit/?id=3cb845283eb430c9b905dc0b17d83e5ff8f0c0de. It names some previously unnamed enums. Thanks @trungnt2910, it makes our code cleaner . But now the question is whether we should support R1/B4, and make our code a little messier, or just make sure it runs on R1/B4. It must be about time to release R1/B5 
.
2 Likes
Thanks @trungnt2910, it makes our code cleaner
.
Not a Python enthusiast myself, but great to hear that my code has made positive impact beyond my own projects
whether we should support R1/B4
Beta releases are probably called “Beta” for a reason. Things are bound to change, even among Haiku apps themselves. Therefore, in my opinion, it is not really worth it.