Override python version

Is it possible when building 23.05.0, to override python version to 3.10 (not 3.11)? Need this for size reasons

1 Like

The question looks simple and the answer is: Yes, it is possible.

Maybe you are looking at how to do it. Well, you need to look how it is done and how the Python is updated in OpenWrt.

This commit could be a very good reference for you:

It also provides steps on how you can do it.

Anyway, I doubt that downgrading Python is a solution here.

1 Like

Thank you so much.

I meant to ask if there's config option for that.
A commit is an excellent reference as well.

Anyway, I share your doubt. Here's my reasoning.

  • I need the image to be under 13mb, and it's now 15mb (was 12.9 with 22.03.5).
  • I compared .config files and didn't find major differences.
  • I explored boxes installed with our image based off 22.03.5 vs. 23.05.0.
  • python3.10 was 13mb, and 3.11 is 21mb (du -h).
  • My application does not require 3.11, so I thought I'd give it a try.

Hi Rama,

Where you able to do the downgrade of python version succesfully?
I have a similar situation with a project that had a 6 year old LEDE build and used python 2.7 with limited flash memory.

I successfully made a 23.05 image and started the pyhton 2.7 to 3.11 migration of the app work.
It failed since the size of python code compiled was to big.
I backed down to 22.03 that has python 3.10.
Now suddenly the compiled .pyc files are smaller and i have space left.

I completely share your view that it is a problem for a small embedded system that python 3.11 takes much more space.

Thanks for your feedback!

I was not able to downgrade python, no.

I tried to patch --reverse the attached, too naiive.

I tried to use 23.05.0 and just change the python version in respective Makefiles, but this didn't work, as the 23.05.0 package repo does not contain python 3.10.

I looked into using more than one repo, but it is not straightforward and would take quite long to achieve and make it work.

My thought is that python no longer fits into tiny embedded systems. In terms of disk/image size as well as memory usage.

I've not tried this approach but I would suggest trying the following based on replacing the standard python package structure with the 22.03.5 one:

  • create a new checkout of your target branch
  • update then install the package feeds in the target checkout
  • create a separate checkout of 22.03.5 (which currently has Python 3.10.9)
  • update then install the package feeds in the 22.03.5 checkout
  • delete everything under ./feeds/packages/lang/python in the target checkout
  • copy everything under ./feeds/packages/lang/python in the 22.03.5 checkout to ./feeds/packages/lang/python in the target checkout
  • make defconfig/menuconfig etc in the target checkout

This will not change the config (as the Python version is not configurable via kconfig) but it should allow you to build Python 3.10.x (with matching packages) instead of Python 3.11. Note that this approach is likely at odds with common git usage as far as maintenance is concerned (I'm old school going back to SCCS/RCS and build from specific checkouts; I don't try and follow branches and rebuild etc). If need be, you could probably script the process but I expect over time that the compatibility between package files in different versions will diverge and building will become increasingly difficult.

1 Like

Genius approach (and thank you for spelling it out :slight_smile: )

You suggest, roughly, to

  • initiate two openwrt builds, one against each of 22.03.5 and 23.05.0.
  • once feeds update and install are done (in either),
    replace 23.05.0 python with 22.03.5 python (/feeds/packages/lang/python)
  • proceed with the build of 23.05.0.
    right?

I'll try that and reply here

Yes, but just to be clear: where you write "(in either)" that should be "(in both)".

Additionally:

  • your target checkout can be a branch (i.e. 23.05) rather than a specific tag (though a specific tag also works if that's what you want)
  • I suggest the source checkout needs to be for a specific tag (i.e. 22.03.5) rather than for a branch because I'm uncertain whether the 22.03 branch package feeds might get updated to a later Python release (I haven't figured out exactly how the package feeds are managed at this point - it may not matter if dev policy is not to make major upgrades to language packages in branch feeds)

Something I hadn't thought through :frowning: that may get in the way relates to the various package feed files and links, so you may still encounter some issues arising from that; if that is a problem you'd then need to look at the details of the feeds script to see whether you can extract the commands that regenerate those files and links from the modified ./feeds/package tree (perhaps just re-running ./scripts/feeds install -a might be enough??; in that case you might only need to do the feed update before the package copy then feed install after the copy...) You might have to experiment a bit but essentially you're trying to make make the older Python package set into something like a private feed, which would be the best course if you need to maintain this long term.

1 Like