Help needed with building an spk for home assistant (python3-based app) #1654
Comments
|
Your description isn't completely clear to me, but I believe you might be referring to the difference between DEPENDS and BUILD_DEPENDS. As an example, the Mercurial package uses that approach: Line 7 in 03f583a Fwiw, try to replicate the approach of |
|
@Dr-Bean you're right, I confused DEPENDS and BUILD_DEPENDS. This helped a lot, thanks! After changing that, I could build the package (including PyYaml and netifaces as cross-compiled wheels), but adding pyephem as a wheel didn't go well. I took my netifaces wheel as an example, but I think there is something wrong in the pyephem Makefile that causes spksrc not to understand what it should do. It doesn't even download the package source.. The changes I made are at master...wind-rider:homeassistant It doesn't matter whether I try to quickly build pyephem from its cross folder or by referencing it from my spk folder. Could you explain to me what's going wrong? See the log below: |
|
Not all Python modules are ready for wheels, and that might also be the case for pyephem. See the wiki page on the wheels subject for some suggestions (near the bottom of the page): https://github.com/SynoCommunity/spksrc/wiki/Using-wheels-to-distribute-Python-solutions. There might be some patching involved, but that's impossible to say without looking at the code itself. |
|
I see. However, it seems that spksrc doesn't even download the sources (I also tried with spksrc.python-module.mk instead of spksrc.python-wheel.mk). This makes it look as if the Makefile or another file is broken. Do you see anything strange in the pyephem files? |
|
If the download doesn't even start, and with the errors you showed above, you're right that there must be a mistake or two in the Makefile. |
|
One addition: the current python_wheel.mk renames the cross-compiled wheels in this line: https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.python-wheel.mk#L29. I'm not going into detail here, but that renaming action is specific to python2, because that's what the code was written for. The issue you might run into is that during package installation, the python3 installer doesn't recognize the original name that the wheel ends up as (which is If the wheel is not recognized, you can override the format by defining an |
|
Great, thank you for thinking along! I also stumbled upon pip not recognizing the wheels and decided building everything as modules for a working first build. Also I decided to comment out some optional modules, to try to first create a small version that actually runs. I'm close now, I'll commit it when I make some progress :) |
|
You mean pip doesn't recognize the cross-compiled wheels during creation of the package? That's the same issue. If you implement the approach I mentioned above, that should fix it. |
|
I created a basic working version now at master...wind-rider:homeassistant The server starts at port 8123 and works already with Philips hue and some python-based components. The following still needs some attention for which I could use some assistance (expecially with the pid logic and log files):
|
|
Try using busybox' |
|
About https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.python-wheel.mk#L29 that you mentioned - I see linux_i686 there. I think that line doesn't work well here - I'm using your Docker environment in Ubuntu 14.04 64-bit. In the Docker file Debian Jessie 32 bit is defined, but still I see wheels like pyephem-3.7.5.3-cp27-none-linux_x86_64.whl in the wheelhouse folder. Two questions:
|
|
Yes, that would work (it's essentially the same thing as I suggested before) |
|
I updated my comment above to make it more clear, but after that I saw that you already responded. One more question - why is |
|
See https://www.python.org/dev/peps/pep-0427/#file-name-convention and https://www.python.org/dev/peps/pep-0425/#details for a bit of background. When (cross) compiling, the |
|
Can it be that these py2 etc wheels are downloaded because of the PIP definition in spksrc.common.mk? I think it won't be a problem as wheels are still downloaded by pip3.4 in installer.sh. |
|
I could use a bit more context here... As for pure-python wheels: those end up with a As for how to 'force' a py3 tag instead of a py2 tag, you'll probably need to use python3's pip, instead of python2's pip. In other words, Python3 should be installed on the host, pip should be installed for that Python version, and common.mk should reference a |
|
What I meant was: I also think pip3 should be used to download python 3 wheels, but in spksrc.common.mk, the variable PIP is hardcoded to 'pip' instead of depending on the compilation. Is this done on purpose? |
|
To be clear, platform/python-specific wheels are never downloaded, those are always created locally. The reason that you end up with two wheels is because Python2's pip doesn't recognize the cross-compiled wheel as valid, because Python2's pip only wants a cp27 tag, and rejects the cp34 tag on the existing wheel. So, it attempts to create a cp27 version of it, and that won't work, because it's not cross-compiled. |
I'm trying to build an spk for Home Assistant / https://github.com/balloob/home-assistant.git. It is a promising home automation server written in Python 3.
I've created a basic setup for it at f013a38.
The dependencies build now, but it starts the "stripping binaries" build step based on the PLIST from the work directory instead of from the spk/homeassistant directory. This causes spksrc trying to find binaries that are not built.
Can anybody give me some hints in the right direction?
The text was updated successfully, but these errors were encountered: