[SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

newsboost · 2022-06-10 12:57:28

Hi

I discovered that in order to run a given program I need to use python 3.9, but the default python I have installed is 3.10.5. My question now is: What is the recommended method, to use a package not for the system-python, but for the older 3.9 ?
I'm aware that the system by default installs to /usr/lib/python3.10/site-packages - so in my case I want a package dependency to exist below /usr/lib/python3.9/site-packages. I first tried manually copying everything for that package as root... Then I considered if this was the moment I need virtual environments - or if there's another way? In any case, I would like to ask, what is the best/recommended what? I guess if I use some virtual environment then we're back at using "pip install" unless there's a way to still use pacman ? It could be interesting, if there's a way to still use pacman, because I guess at some time python 3.9 *was* the latest and greatest... Maybe I should see if I can get a snapshot from the python 3.9-days? But then again, that probably interferes with other some packages?

What's your opinion on this (what's the recommended way for Arch linux)?
Thanks!

Last edited by newsboost (2022-06-11 01:23:48)

Trilby · 2022-06-10 13:59:36

Python39 is in the AUR. That's what I'd use. Though I'm pretty sure virtual-env / venv / whatever would also be a good solution, but I have next to zero experience with those.

Manually copying files as root is a bad idea (especially if you are just making copies of 3.10 and calling them 3.9). Please undo that or remove those copies if you haven't already.

Last edited by Trilby (2022-06-10 14:00:27)

newsboost · 2022-06-10 17:04:34

Trilby wrote:

Manually copying files as root is a bad idea (especially if you are just making copies of 3.10 and calling them 3.9). Please undo that or remove those copies if you haven't already.

Right I did this, but it didn't work, so I quickly deleted those manually copied files again... My next question: Is it possible to somehow go back in time at that time where Python 3.9 was the latest and the use pacman to install things as it did at that time?

If this is not possible, I guess virtual environment is the only solution, although I also do not have experience with this. So hope to hear if there is a "pacman"-solution (ideally so AUR also works with python 3.9 instead of 3.10) or also if this is simply not possible to use a previous version of the pacman-database?

Trilby · 2022-06-10 17:26:40

newsboost wrote:

Is it possible to somehow go back in time at that time where Python 3.9 was the latest and the use pacman to install things as it did at that time?

Do you have a spare flux-capacitor?

Joking aside, there is the arch linux archive - but that would be a bad idea for this situation. You don't want to downgrade python globally as that would break all other packages that depend on it.

You want to install 3.9 side-by-side with the current 3.10, and this is exactly what the AUR package I referred to is for. This AUR package, once built, would be installed with pacman. This AUR package is designed for exactly the purposes you have stated in this thread and sounds like precisely what you want. What's the hesitation? Use the python39 AUR package.

Last edited by Trilby (2022-06-10 17:26:56)

newsboost · 2022-06-10 19:52:32

Trilby wrote:

You want to install 3.9 side-by-side with the current 3.10, and this is exactly what the AUR package I referred to is for. This AUR package, once built, would be installed with pacman. This AUR package is designed for exactly the purposes you have stated in this thread and sounds like precisely what you want. What's the hesitation? Use the python39 AUR package.

I'm sorry, you don't understand the situation and maybe it's my mistake because maybe I haven't expressed this clearly enough: I already installed python39 from AUR, but I need another package to be installed and coexist with python39 (some plotting jupyter-plot-stuff, think similar matplotlib, except it's not matplotlib, I cannot currently remember the exact package name) because neither the pacman nor the aur-database no longer works for the /usr/lib/python3.9/site-packages-directory.

We all know that the AUR and pacman-database *HAS* worked for the /usr/lib/python3.9/site-packages-directory because before python 3.10 became the "new default standard" that's where all the packages became installed into maybe a year ago (or whatever, I haven't checked when the change happened). So that's why I'm talking about virtual environment or not, i.e. "go back in time", if something else exists. I don't think you understood this part so I hope I'm making it more clear now.

I can also be *EVEN* more clear than before: Is there a working procedure to install pacman/AUR-packages into the /usr/lib/python3.9/site-packages-directory, because when I tried manually copying from the /usr/lib/python3.10/site-packages-directory it didn't work? Again: This is not a random directory, this is the directory where things used to be installed into, just before python 3.10. I think this should be clear enough now.

Last edited by newsboost (2022-06-10 19:59:28)

loqs · 2022-06-10 20:17:09

newsboost wrote:

I need another package to be installed and coexist with python39 (some plotting jupyter-plot-stuff, think similar matplotlib, except it's not matplotlib, I cannot currently remember the exact package name) because neither the pacman nor the aur-database no longer works for the /usr/lib/python3.9/site-packages-directory.

In what form do you have this package currently?

newsboost wrote:

I can also be *EVEN* more clear than before: Is there a working procedure to install pacman/AUR-packages into the /usr/lib/python3.9/site-packages-directory, because when I tried manually copying from the /usr/lib/python3.10/site-packages-directory it didn't work? Again: This is not a random directory, this is the directory where things used to be installed into, just before python 3.10. I think this should be clear enough now.

Is this a PKGBUILD that is placing the files in /usr/lib/python3.10/site-packages instead of /usr/lib/python3.9/site-packages or some command you are executing or an archive you extracting?

Last edited by loqs (2022-06-10 21:20:09)

Trilby · 2022-06-10 21:35:30

Content under /usr/lib/python3.9/ would often be built differently than content belonging to the same python package under /usr/lib/python3.10/, so getting a package just to move the files isn't sufficient. But anything that is packaged for 3.10 can trivially be built for 3.9. But this is not about installing into a certain directory, it's building for a certain python version. Pacman does not "by default" install to the 3.10 directory, it installs to the root directory, and files within the package may have paths including python3.9 or python3.10.

You are correct though that I misunderstood the initial question. You just want to know how to build some unspecified package for 3.9 - but in order to answer we should know the package ... not just that it is "similar matplotlib, except it's not matplotlib". If it were matplotlib, I suspect the only changes needed to the PKGBUILD would be to change the calls to "python" in the build / check / package functions to python3.9.

Last edited by Trilby (2022-06-10 21:42:53)

newsboost · 2022-06-10 22:18:04

loqs wrote:

In what form do you have this package currently?

I don't have this package in any form, because all Pacman/AUR-packages use python 3.10 instead of 3.9, as far as I know... But all packages used to use python 3.9, that's why I've written about "go back in time" and am asking if that is a solution or recommended - I suppose all packages with a PKGBUILD-file have previuos versions in git, so is it a solution to use that previous version from python 3.9 or should one only use a python virtual environment?

loqs wrote:

Is this a PKGBUILD that is placing the files in /usr/lib/python3.10/site-packages instead of /usr/lib/python3.9/site-packages or some command you are executing or an archive you extracting?

No, I don't have a PKGBUILD-file. But I suppose it can be found because I suppose there used to exist a previous version that used python 3.9 for all packages, right? As far as I know (please correct me if I'm wrong), then *ALL* pacman/AUR-packages use python 3.10 instead of 3.9, hence the talk about "going back in time" to a previous PKGBUILD, I suppose? I haven't tried it - am just asking in general, what is the procedure, because 99% of the time I always use python-packages with the latest python-version. Now I need to use an older python-version but all Pacman/AUR-packages are made only for the latest python-version (3.10) and not for (3.9). I hope it's more understandable now, what I'm trying to do and why...

newsboost · 2022-06-10 22:26:52

Trilby wrote:

Content under /usr/lib/python3.9/ would often be built differently than content belonging to the same python package under /usr/lib/python3.10/, so getting a package just to move the files isn't sufficient. But anything that is packaged for 3.10 can trivially be built for 3.9. But this is not about installing into a certain directory, it's building for a certain python version. Pacman does not "by default" install to the 3.10 directory, it installs to the root directory, and files within the package may have paths including python3.9 or python3.10.

But pacman/AUR-packages as far as I know are only made for the latest python-version, so when I install a python-package via Pacman/AUR it becomes installed into /usr/lib/python3.10/... and not /usr/lib/python3.9. I know it's a bad idea to use pip and it's better to use the package-system so things can be uninstalled/cleaned fully when removing the package again. But I suppose either that or virtual environment (haven't tried that) or figure out how to install via pacman/AUR into /usr/lib/python3.9...

Trilby wrote:

You are correct though that I misunderstood the initial question. You just want to know how to build some unspecified package for 3.9 - but in order to answer we should know the package ... not just that it is "similar matplotlib, except it's not matplotlib". If it were matplotlib, I suspect the only changes needed to the PKGBUILD would be to change the calls to "python" in the build / check / package functions to python3.9.

Well, the question was general. But at least one of the packages I want inside /usr/lib/python3.9 is "python-occ-core" - otherwise the python-code will not work without, just like it's not possible to run a python3.9 program that requires matplotlib, if it's (=matplotlib is) not installed into /usr/lib/python3.9/... I don't have a PKGBUILD, but I suppose it can be found somewhere, but maybe it's possible to fetch a previous version from when things were installed into /usr/lib/python3.9/ and then again use pacman to uninstall when done, so things are cleaned up nicely without leaving any files...?

Last edited by newsboost (2022-06-10 22:27:54)

loqs · 2022-06-10 22:29:46

newsboost wrote:

loqs wrote:
In what form do you have this package currently?
I don't have this package in any form, because all Pacman/AUR-packages use python 3.10 instead of 3.9, as far as I know... But all packages used to use python 3.9, that's why I've written about "go back in time" and am asking if that is a solution or recommended - I suppose all packages with a PKGBUILD-file have previuos versions in git, so is it a solution to use that previous version from python 3.9 or should one only use a python virtual environment?

Depends if the package in question has any decencies apart from the python package. Can you not provide the name of this package and the name of the application that requires python3.9? It would allow for much more targeted support.
Edit:
pythonocc-core assuming you use a clean chroot so only python39 will be found by cmake the minimal changes would be:

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 69dc3db..8fef227 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -1,7 +1,7 @@
 # Maintainer: Filipe Laíns (FFY00) <lains@archlinux.org>
 
 _pkgname=pythonocc-core
-pkgname=python-${_pkgname#python}
+pkgname=python39-${_pkgname#python}
 pkgver=7.5.1.r90.g141c53f7
 _commit=141c53f716ca4c138a6ddee2ce6ed1d3c28944e8
 pkgrel=1
@@ -9,7 +9,7 @@ pkgdesc='Python package for 3D CAD/BIM/PLM/CAM'
 arch=('x86_64')
 url='https://github.com/tpaviot/pythonocc-core'
 license=('LGPL3')
-depends=('python' 'opencascade' 'libxmu' 'libxi')
+depends=('python39' 'opencascade' 'libxmu' 'libxi')
 # rapidjson appears to be unused but an opencascade
 # header that references it gets dragged in somehow
 makedepends=('cmake' 'swig' 'rapidjson' 'git')

Other packages would depend on dependencies and build system.

Last edited by loqs (2022-06-10 22:47:41)

Xyne · 2022-06-10 22:47:28

Just use a virtual environment. It's so much simpler than shimmying down the partial upgrade slope that you're on. Here's a simple starting point but you'll have to update the array of PyPI packages with whatever you actually need.

#!/usr/bin/bash
set -euo pipefail

# Add the required package names to the following array. The packages below are provided as an example.
# Find the names on https://pypi.org/
PYPI_PKGS=(
  pandas
  jupyter
  matplotlib
  seaborn
)

VENV_DIR=$(readlink -f venv)
/usr/bin/python3.9 -m venv "$VENV_DIR"
source "$VENV_DIR/bin/activate"
"$VENV_DIR/bin/python" -m pip install --upgrade pip
"$VENV_DIR/bin/python" -m pip install --upgrade "${PYPI_PKGS[@]}"
echo "To activate the virtual environment: source ${VENV_DIR@Q}/bin/activate"

This will require the python39 package with the python3.9 executable. Run the script to create the virtual environment then activate it with "source venv/bin/activate". After that, you should be able to do whatever you need to do.

Incidentally, most Python PKGBUILDs will build a package for whatever version of the Python interpreter is used to build them. The PKGBUILDs on the AUR tend to specify "python" or "python3" but not the minor version (e.g. python3.10). It simplifies upgrading and even downgrading, but downgrading is not supported due to the myriad of problems that it introduces.

edit Just to clarify the last point, if you run makepkg on a Python PKGBUILD and the only "python" or "python3" that it sees is python3.9 then it will build a Python 3.9 package, which is why loqs suggested a chroot.

But again, just use a venv if you can.

Last edited by Xyne (2022-06-10 23:00:20)

newsboost · 2022-06-10 23:50:15

loqs wrote:

pythonocc-core assuming you use a clean chroot so only python39 will be found by cmake the minimal changes would be:

diff --git a/trunk/PKGBUILD b/trunk/PKGBUILD
index 69dc3db..8fef227 100644
--- a/trunk/PKGBUILD
+++ b/trunk/PKGBUILD
@@ -1,7 +1,7 @@
 # Maintainer: Filipe Laíns (FFY00) <lains@archlinux.org>
 
 _pkgname=pythonocc-core
-pkgname=python-${_pkgname#python}
+pkgname=python39-${_pkgname#python}
 pkgver=7.5.1.r90.g141c53f7
 _commit=141c53f716ca4c138a6ddee2ce6ed1d3c28944e8
 pkgrel=1
@@ -9,7 +9,7 @@ pkgdesc='Python package for 3D CAD/BIM/PLM/CAM'
 arch=('x86_64')
 url='https://github.com/tpaviot/pythonocc-core'
 license=('LGPL3')
-depends=('python' 'opencascade' 'libxmu' 'libxi')
+depends=('python39' 'opencascade' 'libxmu' 'libxi')
 # rapidjson appears to be unused but an opencascade
 # header that references it gets dragged in somehow
 makedepends=('cmake' 'swig' 'rapidjson' 'git')

Other packages would depend on dependencies and build system.

Ok, I didn't knew that, thanks. So I tried to ask the question in general so I would/could learn also. But you write it's very specific on a case-by-case-basis and frankly this doesn't sound too easy always. I didn't know if there were an easy solution. Also to answer myself, I've now been looking a bit and found e.g. https://github.com/archlinux/svntogit-c … 42cd2ce841 - which I think is the MAKEPKG-file from that moment where python3.9 was the "latest" and this also uses "depends=('python' 'opencascade' 'libxmu' 'libxi')" - which isn't good enough when the python-version gets bumped up to 3.10. I maybe hoped there was some kind of built-in mechanism or system to solve this in a more "automatic" way, but apparently there isn't and one has to manually look into the MAKEPKG-file and manually modify what needs to be modified. This is not so "noob"-friendly, but I suppose that's just how it is - i.e. it's a limitation in the pacman/AUR-system - or maybe an "unsupported feature". Thanks for making this clear to me!

In this case, I can see you (except for pkgname, which shouldn't mean anything) only changed the "depends"-line from python to python39 - I'm surprised that is possible, because then the system somehow must also know that "python39" will have it's packages installed into /usr/lib/python3.9/... Anyway, I can also see Xyne posted a "virtual environment"-solution and it currently initially looked a bit easier... But maybe I'll end up doing what you just showed, I'll answer the issues I now see with the virtual-environment-solution, thanks!

Trilby · 2022-06-11 00:06:53

newsboost wrote:

But pacman/AUR-packages as far as I know are only made for the latest python-version, so when I install a python-package via Pacman/AUR it becomes installed into /usr/lib/python3.10/... and not /usr/lib/python3.9.

That's only if and because they were built for the 3.10 version. They can be built for any version, and then when installed they'd populate that version's directory. But as noted above, it is now sounding like a virtual env would be better. The current system doesn't decide where these files get installed, the package itself (and thus how it is built) determines which python directory the content is installed to.

Last edited by Trilby (2022-06-11 00:08:06)

newsboost · 2022-06-11 01:22:46

Xyne wrote:

Just use a virtual environment. It's so much simpler than shimmying down the partial upgrade slope that you're on. Here's a simple starting point but you'll have to update the array of PyPI packages with whatever you actually need.
...
...
/usr/bin/python3.9 -m venv "$VENV_DIR"
source "$VENV_DIR/bin/activate"
"$VENV_DIR/bin/python" -m pip install --upgrade pip
"$VENV_DIR/bin/python" -m pip install --upgrade "${PYPI_PKGS[@]}"
echo "To activate the virtual environment: source ${VENV_DIR@Q}/bin/activate"

Thanks a lot for showing it! I just tried it - however there's a new issue, I've been struggling with for some hours - but I think I've solved it, hooray!

First: I thought practically all python-packages were on pypi.org. But it seems that the "pythonOCC"-stuff is not there, at least I've tried to search for it but suspect it isn't there at all. The documentation for the "pythonocc-core"-package is here: https://github.com/tpaviot/pythonocc-core - it seems instead of this "venv" / virtual environment, the author writes one should use "conda". He specifically also writes:

pythonocc provides precompiled conda packages (they depend on third part libraries made available from the dlr-sc and conda-forge conda channels) for python 3.7, 3.8 and 3.9.

I think this means that the author has decided to not distribute the library through pypi and nobody else has distributed this package via pypi ? Anyway, this got me started thinking... My first thought was: I know on Windows a lot of people use anaconda, but this is like another layer of package management, isn't it? I suppose I need to install "anaconda" via pacman, then type the 3 lines he typed and cross my fingers... So that's what I did... But it was again not straightforward easy: Installing anaconda was really slow and I think it took up almost 4 GB of disk space! While it was installing I had time to google around and think and I found out I should just uninstall the 4 GB anaconda bloatware (or whatever it is) and just install (https://aur.archlinux.org/packages/python-conda):

yay -S python-conda

Next I tried:

conda create --name=pyoccenv python=3.9
source activate pyoccenv
...
pkg_resources.DistributionNotFound: The 'ruamel_yaml_conda>=0.11.14' distribution was not found and is required by conda

But something happened with this "ruamel_yaml_conda"-stuff so I googled and came across https://aur.archlinux.org/packages/python-conda where this exact error message is mentioned on May 13th - 2-3 weeks ago. And a few solutions are also written there, I took the one I thought was the best and it was to upgrade https://archlinux.org/packages/extra/an … etuptools/ because my system version of python-setuptools 1:60.6.0-1 was not working (repos: extra), but this package also exists in a "testing"-repo, where it is newer and has version 1:60.10.0-1. I downloaded the package, installed it with:

sudo pacman -U python-setuptools-1\ 60.6.0-1-any.pkg.tar.zst

- and then I could activate the virtual environment (and it also wanted me to do some kind of init):

conda activate pyoccenv
conda init zsh

Finally I could do as the author had described + I installed wxpython too:

conda install -c conda-forge pythonocc-core=7.5.1 occt=7.5.1
conda install -c conda-forge wxpython

This was initially complicated but now I think I understand it. I must confess having gone through this, that I can see that virtual environments is much easier to deal with because at least in this example there are many dependencies that will automatically be fixed with a virtual env like this - which wouldn't be fixed with the earlier discussed method of manually doing changes to MAKEPKG for each and every individual package... When dependencies are involved, that becomes too tedious I think...

Xyne wrote:

This will require the python39 package with the python3.9 executable. Run the script to create the virtual environment then activate it with "source venv/bin/activate". After that, you should be able to do whatever you need to do.
Incidentally, most Python PKGBUILDs will build a package for whatever version of the Python interpreter is used to build them. The PKGBUILDs on the AUR tend to specify "python" or "python3" but not the minor version (e.g. python3.10). It simplifies upgrading and even downgrading, but downgrading is not supported due to the myriad of problems that it introduces.

Ok, I understand... Thanks for pointing it out - also despite that in the end I think the solution for this package was to use "conda" instead of "venv" - but the principle is the same, I think, so thanks a lot for showing this to me. I couldn't find my package on pypi.org, but apparently conda has another repo for python-packages, where this originates from...

Xyne wrote:

edit Just to clarify the last point, if you run makepkg on a Python PKGBUILD and the only "python" or "python3" that it sees is python3.9 then it will build a Python 3.9 package, which is why loqs suggested a chroot.
But again, just use a venv if you can.

Okay, so one can also uninstall python3.10 and then install the relevant packages - but I prefer not to go through the hazzle of then having to reinstall everything afterwards. Furthermore I think there will be problems if I have to update and run "pacman -Suyy"... But everything seems to work now, so I think I'll just mark the thread as solved, thanks a lot for helpful and kind support, all!

Xyne · 2022-06-11 13:45:05

newsboost wrote:

Okay, so one can also uninstall python3.10 and then install the relevant packages - but I prefer not to go through the hazzle of then having to reinstall everything afterwards. Furthermore I think there will be problems if I have to update and run "pacman -Suyy"... But everything seems to work now, so I think I'll just mark the thread as solved, thanks a lot for helpful and kind support, all!

Uninstalling python3.10 would create problems for packages that depend on it and during the process you would again be in a partial upgrade state. The risk is not worth the reward.

I'm glad that you got it working with conda. Just FYI, it is also possible with venv if you compile pythonocc yourself. I started the compilation as a test but didn't have time to let it finish. Here's the process for future reference:

Install the venv with the previous script.
Install all of the build dependencies for python-occ (opencascade, libxmu, libxi, and apparently swig).
Activate the venv with source <venv path>/bin/activate.
Follow the build instructions for python-occ (mkdir build, cd build, cmake .., make).
Install python-occ in the venv: make install DESTIR=<venv path>

Admittedly I haven't tested step 5 but it should "just work". I assume Conda creates an equivalent local installation with the pre-compiled binaries.

Btw, I have a question that should have been asked at the beginning of the thread: which Python package do you need that's incompatible with Python 3.10? The python-occ-core package is in the official repos so it can't be that. So which program was causing the problem?

newsboost · 2022-06-11 15:10:36

Xyne wrote:

Uninstalling python3.10 would create problems for packages that depend on it and during the process you would again be in a partial upgrade state. The risk is not worth the reward.

Yes, I fully see that now, that was pretty unclear to me at the beginning because usually there I don't have this problem...

Xyne wrote:

I'm glad that you got it working with conda. Just FYI, it is also possible with venv if you compile pythonocc yourself. I started the compilation as a test but didn't have time to let it finish. Here's the process for future reference:
Install the venv with the previous script.
Install all of the build dependencies for python-occ (opencascade, libxmu, libxi, and apparently swig).
Activate the venv with source <venv path>/bin/activate.
Follow the build instructions for python-occ (mkdir build, cd build, cmake .., make).
Install python-occ in the venv: make install DESTIR=<venv path>
Admittedly I haven't tested step 5 but it should "just work". I assume Conda creates an equivalent local installation with the pre-compiled binaries.

Thank you very much, also very valuable and I think I'll se if I can spend some time testing this - at least not, just for the learning experience so in the future I can better handle these/such problems quickly! I actually started compiling yesterday (but not with venv-environment, just wanted to see if I could learn how things work and hoped it would be quick - as you also discovered, it doesn't compile quickly, it takes quite a while so better do something else in the meanwhile). Yesterday compilation failed, but today I realized, you/we need a dependence: "yay -S rapidjson" to fully compile... I'll definately try what you wrote above.

I'm also thinking that maybe I can "convert" the conda-stuff to a local MAKEPKG-file... And then again, maybe not: I've now discovered that everything in ~/.conda/envs/pyoccenv takes up 1.8 GB - of this,
~/.conda/envs/pyoccenv/lib takes up 1.4 GB and ~/.conda/envs/pyoccenv/lib/python3.9/site-packages is 635 MB - finally ~/.conda/envs/pyoccenv/lib/python3.9/site-packages/OCC takes up 341 MB... Maybe I'll attempt to see if it's possible to create a MAKEPKG file that somehow
copies ~/.conda/envs/pyoccenv/lib/python3.9/site-packages/OCC into my system /usr/lib/python3.9/site-packages/OCC - but probably more stuff needs to be done and probably it won't work... But I'll learn something, maybe I'll try tomorrow now that it's weekend I got more sparetime for these things than in the evenings of normal workdays...

Xyne wrote:

Btw, I have a question that should have been asked at the beginning of the thread: which Python package do you need that's incompatible with Python 3.10? The python-occ-core package is in the official repos so it can't be that. So which program was causing the problem?

Yes, no problem, it's fine you're asking. There are some problems in (at least 1) a dependency in the python-occ-core package, which will become more obvious, once you (or we) begin trying the python example scripts... As an example, if you clone the pythonocc-demos/examples folder and then try to run "./core_classic_occ_bottle.py" it'll come up with the following error:

Traceback (most recent call last):
  File "/home/user/Downloads/pythonocc-demos/examples/./core_classic_occ_bottle.py", line 232, in <module>
    display, start_display, add_menu, add_function_to_menu = init_display()
  File "/usr/lib/python3.10/site-packages/OCC/Display/SimpleGui.py", line 208, in init_display
    win = MainWindow()
  File "/usr/lib/python3.10/site-packages/OCC/Display/SimpleGui.py", line 177, in __init__
    self.centerOnScreen()
  File "/usr/lib/python3.10/site-packages/OCC/Display/SimpleGui.py", line 184, in centerOnScreen
    self.move(x, y)
TypeError: arguments did not match any overloaded call:
  move(self, QPoint): argument 1 has unexpected type 'float'
  move(self, int, int): argument 1 has unexpected type 'float'

I cannot exactly remember where I found this information, but obviously I googled and I think I traced this back to something that changed between python 3.9 and 3.10. So maybe in 6-12 months everything will be updated and fixed properly, but right now I don't see any other way than to use some kind of virtual environment, in order to run with python 3.9 instead of 3.10... It's not the maintainers fault - I think this is also not just an issue with python-occ, it's something that'll affect a lot of projects, see e..g. https://bugs.launchpad.net/rapid/+bug/1946407 ; https://bugzilla.redhat.com/show_bug.cgi?id=1901925 ; https://github.com/tzutalin/labelImg/issues/811 - so virtual environment comes to rescue here (I prefer avoiding those, but here I'm forced to use it, eventually I guess all packages will be updated and the problem disappears)...

Arch Linux

#1 2022-06-10 12:57:28

[SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#2 2022-06-10 13:59:36

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#3 2022-06-10 17:04:34

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#4 2022-06-10 17:26:40

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#5 2022-06-10 19:52:32

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#6 2022-06-10 20:17:09

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#7 2022-06-10 21:35:30

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#8 2022-06-10 22:18:04

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#9 2022-06-10 22:26:52

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#10 2022-06-10 22:29:46

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#11 2022-06-10 22:47:28

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#12 2022-06-10 23:50:15

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#13 2022-06-11 00:06:53

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#14 2022-06-11 01:22:46

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#15 2022-06-11 13:45:05

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

#16 2022-06-11 15:10:36

Re: [SOLVED] Install to Python 3.9 instead of (default) Python 3.10 ?

Board footer