Request: Python3-cffi

[xmun2k]

Installing cffi on embedded devices is something of a nightmare. Would it be possible to have a package for Python3? There is one already for Py2

[hnyman]

fyi: @jefferyto @commodo

[commodo]

Thanks @hnyman for pointing this out. Will take a look.

@jefferyto @hnyman just a thought [i've been having for a while now] ; not proposing anything yet.

would it be worth starting a python [ python & python3 ] feeds repo ? to isolate damage from Python packages in other packages ; as well as reduce build times ;

i admit, i don't have a good idea about handling packages that have python extensions ; maybe you have some input here; not sure yet how many python packages exist yet in this case ; will take a look at that too

atm, i have to do some updates on a few packages i maintain

[hnyman]

would it be worth starting a python [ python & python3 ] feeds repo ? to isolate damage from Python packages in other packages ; as well as reduce build times ;

having a separate repo does not change build times as long as the feed is enabled by default. A separate repo could just help in directing issues and PRs, but I guess that many people would still report issues in the "main packages" repo without recognising the difference.

The question about a new separate repo is more for the core devs...

[commodo]

understood

well, maybe i'll bring it up in a larger audience later ; one [main] reason for me proposing this, is my fragmented involvement in maintaining Python(3) ; for most times the Python eco-system seems fine/stable/working ; this is judged mostly on the number of issues I have to look at [ which is reasonable ]

then [sometimes] after an upgrade/update, there's a week [or so] of breakage and firefighting ; this hasn't happened in a while ; so, let's see

[jefferyto]

I'll try to take a look at building cffi for Python 3 "soon" (too busy IRL) - as always, patches welcome :smile:

On a similar topic, I wonder if it's possible to build packages that can depend on any version of Python (e.g. Python packages in Ubuntu/Debian have python:all as a dependency, and then more specific version dependencies as necessary). This wouldn't apply to cffi, but some (a lot?) of the other OpenWrt/LEDE packages I maintain are compatible with both Python 2 and 3. I guess my main question is, is this possible with opkg / the current Makefile format?

[hnyman]

I wonder if it's possible to build packages that can depend on any version of Python (e.g. Python packages in Ubuntu/Debian have python:all as a dependency, and then more specific version dependencies as necessary). This wouldn't apply to cffi, but some (a lot?) of the other OpenWrt/LEDE packages I maintain are compatible with both Python 2 and 3. I guess my main question is, is this possible with opkg / the current Makefile format?

I can think two possible approaches:

1) Using a PROVIDES directive in Makefile. E.g. in iproute2 both ip-full and ip-tiny PROVIDE "ip", and other packages can then depend on "ip" and are fine with either ip-full or ip-tiny being installed. Similarly in LEDE both px5g-polarssl and px5g-mbedtls PROVIDE px5g on which luci-ssl depends.

In python context it would be a bit more difficult as "python" means "python2" and it makes no sense in changing that.

But there could be a new symbol "python-2or3" and both python and pyhton3 could provide that. The packages compatible with either version could then depend on "python-2or3". To work properly and be deterministic in installing a version, it might actually require a new meta-package "python-2or3" that would have two variants (for 2 and 3) and one of the variants would be DEFAULT_VARIANT.

2) Using @ symbol in Makefile to require either python2 or python3 being installed before the package is visible and can be selected. Something like DEPENDS:=@(PACKAGE_python||PACKAGE_python3).

Example: ppp-mod-pppoa:
https://git.lede-project.org/?p=source.git;a=blob;f=package/network/services/ppp/Makefile;hb=HEAD#l64
 `DEPENDS:=@(PACKAGE_ppp||PACKAGE_ppp-multilink) +linux-atm +kmod-pppoa`

But thinking on the rather complex compilation/installation routines of the python package ecosystem in Openwrt/LEDE, I am not sure if the compilation of the packages in the buildbot would be deterministic and if the path parameters etc. can be passed on sensibly.

[commodo]

I'll try a few things using the VARIANT construct ; I also have the same issue, with python-setuptools/python3-setuptools & python-pip/python3-pip.

Maybe using that, would be the sanest approach ; not sure.

[EDIT] I realized I was a bit incomplete ; AFAIK, there's /usr/lib/python3.x & /usr/lib/python2.x folders ; not sure if we should complicate things much further than just maybe putting python3-cffi in the same Makefile as python-cffi and make it a VARIANT. The "problem" with python-setuptools/python3-setuptools & python-pip/python3-pip is that they require 2 commits/PRs to upgrade/update the same thing. I was wondering for a while now for a way of unifying this, and simplifying this [for me]. Maybe the same could be done for all other python & python3 packages

[commodo]

@xmun2k python3-cffi is in

enjoy

if no more objections let's close this :)