Hello, why is PIP not working? n.n should i make a ticket?
Pip was working? I don’t think so…
As a non pyenv code, it “worked”. meaning it installed the packages but you must exit the process manually with a Ctrl C (or Alt variant) to end a endless loop.
On pyenv environments (like some projects use for building their apps like firefox), there was a path error that prevented the pyenv code to run imports ok (folder was wrong).
So… 50% of the time, it worked everytime.
Actually, I found out that instead of “make+make install” a “./build_python.sh” is needed.
Once done that, can try the examples, and they do work. So looks like it is a good start to try to create something for Haiku with Python.
It does not work with Python3 though, only with 2.7.
Thanks @BlueSky!!
Regards,
RR
2 Likes
All the time so many diskussions about dev. languages. Is There a list of available apps written in python?
What I end up with, both with Python and now with Haskell, is this IMAP email application that I use. It works fine - I like it - but I’m sure no one else would be satisfied with it, so I’ve never seriously thought about making it an “available app.”
I wonder what percentage of the software that gets written for Haiku is like that - serves only the person who wrote it and perhaps some associates? My guess would be that it’s the vast majority, and more so on Haiku than typical for other platforms, mainly because of the relative ease with which you can write software here, but also of course the user base is pretty small anyway.
I put that question in terms of software written in whatever, i.e. C++, but Python is sure to lend itself to that, partly because it’s a little easier to work with, and then there’s the difficulty of distributing a program that depends on a particular interpreter installation. If you’re serious, you pretty much have to include the interpreter in the distribution, in a custom install location.
Our package system should cover these needs. You can require a specific version of the interpreter if need be.
And putting up a zipfile of your app somewhere can’t be that hard!
Better use one of those packagers like Nuitka (worked on Haiku), which would bundle both py-dependencies and the program itself. Meaning pip-installed and non in ports or package manager systems, tho.
The non-binary liking people can still download source code and install dependencies if so, and a real haiku package may be done later.
The zipped file method only works if the includes / imports are only of your own.
This is right. But most important to this is to create current running packages. I see so much times packages who does not run currently because lack of description and missing links to the app menu.
Not every package provides deskbar links, CLI programs for example.
Any non-working package or missing deskbar links should be reported on the haikuports issue page.
3 Likes
Good day,
Well, it seems that finally, the Python API Bindings (Healynet) no longer work on an updated Haiku system.
At least they don’t work on my boxes, tried in both (actually both are on the current hrevs, and similar hardware so… nothing strange there).
Did try the install script provided inside the downloaded zip package, did try to install via pip, and did try to get the pip and install from local API file; inside a VENV and global, with Python 2.7 and with Python 3.7. None worked. This is weird as Healynet API bindings for Python did work before.
Therefore, in order to do Python GUI programming on Haiku we are left with:
- PyQt. I tried this with Haiku’s PyQt5 and works quite well, though UI integration does have some issues (some half solved with a flat decorator)
- @aarroyoc Pybind11 approach
The easiest way is go the PyQt way, from what I’ve learned in the past days. I tried to go the wxPython way and nope. It seems wxPython needs to be compiled in Haiku, to be used, or at least I wasn’t able to get it working inside the Python VENV. I might be missing something as my knowledge on these things is still very limited.
So finally, in my case, I’m going to use PyQt to try to get the little Python program I did in GTK running on Haiku, and use what @phw said in the gitcola topic to get integration.
This does not mean I give up on using Haiku native API with Python, it’s just a delay (and as I go slow…mmmm…)
.
If anyone has a different experience on this topic, please let me know. Hopefully sooner than later will be using native Haiku API with Python.
Regards,
RR
2 Likes
AFAIK there were/are different attempts to implement native Haiku API in python, don’t know their actual state. But if you are using Haiku 32 bit (and works only with 32bit versions) you can try Bethon, revisited to work with recent Haiku releases. It works fine and it’s quite complete.
You can find it here
I managed to create this program with it
(Though don’t care the bad use of sqlite i’m not a programmer, I’ve just created it long time ago,because it was missing a nice feed aggregator)
Good day,
Well, I’ve been doing some research lately in order to try to get some Python working. And finally, we have a small success:
What we see here is a PyQt application running on Haiku, with its icon on the deskbar, and can be started from the Terminal as well as with double click on the icon. With the packaging I did for the Awesome app, it could be easily installed in the Applications menu.
Everything I’m learning as I do, so plenty of mistakes I presume. While I used Cython, no Cython code was used, Cython was used only to generate the C file to compile into an executable. This, as I read, is not the intended use for Cython, though it can be done; in fact I read someone used Cython to package PyQt software, though he didn’t say a thing on how he did it, so lot of research here and putting together things from here and there. Nonetheless, this is what I did (all Python3):
0- Create a virtual environment (venv) ‘python3 -m venv --system-site-packages testenv’ (This I did to try to keep my system clean). Using the system site packages because PyQt can’t be installed inside the virtual environment with PIP, and need to have access to PyQt inside the VENV. Inside the virtual environment installed Cython (python -m pip install Cython)
1- Create a GUI with QtCreator, a main window with the menu the tab panel and a label, just to try it out.
2- Save the GUI as mainwindow.ui
3- Convert the .ui to .py file with 'pyuic5 -x mainwindow.ui -o mainwindow.py'
4- With this we can test the mainwindow.py with 'python3 mainwindow.py' (python mainwindow.py inside the virtual environment)
As it did work…
5- Create the icon, export as rdef, and write the full .rdef file, setting application to ‘x-vnd/Superapp’. Convert the .rdef file to .rsrc 'rc superapp.rdef'
6- Use Cython inside the virtual environment to create a .C file with the Python file ’python -m cython --embed superapp.py' resulting in superapp.c
7- Outside of the virtual environment: Compile the C file with the gcc compiler. I did check in advance the ‘python3-config --cflags and -ldflags’ to see the outcome and compare with examples. This I did outside the venv as pyhon-config wasn’t inside the venv. Using python-config instead of python3-config didn’t work, of course:
gcc -o Superapp $(python3-config --cflags) $(python3-config --ldflags) ./superapp.c
8- Then we need to get the Superapp application with the default icon, so need to add the proper icon we designed, which is in the RSRC file,there whe have set the application type to x-vnd/Superapp:
resattr -o Superapp superapp.rsrc
Finally launch the app with double click, and there it is the icon on the deskbar and the app running free on the desktop.
Well, this is a very simple example to check if it works. This app is finally a single file application, and the method I followed is a bit unorthodox, I presume.
Conclusions:
- Using PyQt is quite straightforward to develop interfaces for Haiku. It’s not exactly the same, but depending on the UItheme maybe not so many would notice.
- Finally can make an executable application out of a Python project with Cython. It takes some digging, but could be automated. Nonetheless, we should be carefull as this test is very simple. A bigger project might not work the same way, and I presume it will require a lot more work. There is a lack of documentation on this topic that makes searching very tedious.
- This method, if works for larger projects, could be an easy entry point for those who want to develop Python apps for Haiku.
Well, to be honest, I would like to do this with the Haiku native API, so can use the Layout, and native widgets. For that I’ll need more research, and some help, for sure.
I’ll keep at it.
Regards,
RR
P.S.: By the way, I’m having issues with the ‘venv’. Everytime I do some PIP inside the venv I need to end up using CTRL+C as the PIP python process stays there, forever. This does not happen outside the venv, where PIP just ends the process and returns control to bash prompt. Weird. Any hints?
[Edited]: well, well… it seems that I had to update PIP inside the virtual environment. Now, with PIP updated, no lock. 
Solved!
9 Likes
Good day,
Finally, in case of any Python newbie wants to check this out (and also for me to remember everything), added the whole thing to Gitlab:
Regards,
RR
1 Like
Python has a rule that all 2.x versions will be backward compatible . The same rule applies to Python 3.x versions. However, Python does not guarantee backward compatibility between versions. Python 3 introduced several changes to the actual structure and syntax of the Python language. The whole Python community was pretty much sceptical when they received Python 3.x. Python 3.0 is fundamentally different to previous Python releases because it is the first Python release that is not compatible with older versions . Most of the things written in Python 2.x were not compatible with Python 3.x, as it did not support backward compatibility. Many applications and frameworks needed to rewritten completely due to this, hence, it was very difficult to port to Python 3.x from Python 2.x . Programmers who first learned to program in Python 2.x sometimes find the new changes difficult to adjust to, but newcomers often find that the new version of the language makes more sense.
Python 3 was released in 2008. It’s time to move on. It fixed several annoying problems with the language, including mainly not-so-great handling of non-ASCII text. Sometimes you have to do this kind of thing, otherwise you end up like C++ or Java: a large set of deprecated but still supported features that all developers tell you “oh no you shouldn’t be using that”.
By breaking compatibility a bit (not that much, it didn’t need “complete rewrite” and it was even possible to get code running with both versions with some care), Python avoids this, and remains a nice clean and modern language.
It wasn’t an easy transition to make but it was well worth it.
1 Like
The only thing I quite passionately hate about Python is that it uses indentation to mark blocks of code. That’s form over function at it’s worst for me. Even writing “begin” and “end” in Pascal was better 
But there you go, I guess that won’t be changed in Python 4.
Apart from that, I like Python very much and use it quite a bit.
2 Likes
I think I may have started somewhere around 1.2. I think it reached its apex around 1.54, and after that its development has been mostly unnecessary complications. If they could have stopped right about there and just worked on internals, it would have been a fabulous addition to modern computing - a powerful interpreted language that could be built and run anywhere.
The way it is, it’s awkward to commit to using Python as part of your work, because it’s a moving target you’ll forever need to revisit. All for a boatload of enhancements to support some kind of erotic vision of an ultimate programming language - that’s fundamentally better suited to hackery anyway. It’s lucky the Haiku team seems to like the language, because it could be a bit of a headache to support.
Well, I started studying Python (as my main introduction to the world of programming) around early 2016, I believe I started with Python 3.5. I remember there was a discussing on Python 2 versus 3 at that time. Some packages were not compatible with 3 yet, I chose to focus on Python 3, since it looked like a better bet in the long term.
Then more and more packages started to be based mainly on Python 3, and newer versions became faster. The introduction of f-strings in 3.6 quickly made me decide not to use anything below that version.
I love the syntax and readability of Python, and have no desire to go back to Python 2, which I have heard had some strange old-time quirks with strings… I understand that may experience is completely different from that of a programmer who could have some big projects stuck on older Python versions. But by now, it should not be an issue at all, anymore.
2 Likes
This seems like a useful summary. I believe the issue with strings largely boiled down to using ASCII by default instead of Unicode, despite later support for the latter, and problems coming up with a consistent solution that didn’t break existing code. The lack of a ‘byte’ type for just a single byte is related I think.
Honestly I don’t see that there’s a huge problem with most of those things, so as long as you know what you’re dealing with. There’s no reason to go backwards if you never used Python 2.x, but only a handful of special reasons to always use 3.x. Obviously you shouldn’t mix the two.