VENVs are there for you to collect all you python files (they are just files) all in one place, that include all modules and anything it needs.
This helps because the OS itself has python files that you may update, override and hence break. (It's Debian enforcing this, not so much Python itself, they just created a method to do it after the many many complaints that much of python, pip and system modules couldn't be updated.)
You can disable it on Bookworm with a simple config entry and be on your merry way, perhaps breaking the system, but you are as before in the older OSs.
You can allow it to use the system modules, just a simple override when creating it, or editing a text file if already created so you have flexibility, but you can also install newer modules that you will override the system one but still not break the OS or any other python program on your system.
One big advantage is you could setup your robot with all the modules you need and not trip over the OS not worry about paths and have it working.
Then you think you want to mutex it as they have with i2c? (it's next.to that int he code).
Then if you duplicate that venv activate that one, rather than the working one, you can update modules, downgrade modules, tweak modules and mess with the modules trying things out without effecting the other venvs or the OS with fafy paths that are not working.
If it doesn't work, just delete it, fire up a new one.
It's a big safety net, a few thing needed fixing at the start of PiOS Bookworm but the gpio seems to be fixed (the module version was updated) now so the system wide one doesn't need to be used.
Your problem with updating the robot to Bookworm will actually the kernel and the way Bookworm uses gpio.
This has rendered most older gpio modules obsolete in one go.
So pigpio will not be used, and there will be a rewrite to lgpio or similar.
As a thought, pigpio, which you are using under the hood currently, has an spi bit banging method? Check out Joan's website
It's not venvs causing the problem.with Bookworm.
As for Thonny, they have in their changlogs path stuff in newer versions there has been quite a lot of updates from a program tweak to work on the Pi and then tweak to work well for primary school children.
I think version is in testing now.
Thonny used to run it's own Python version built in, in its vertual setup.
Maybe there is a drop down in the setting for paths or Python versions.
Hope that make some sort of sense and yes we all grumbled back in September too when it was forced upon us![:-)]( "Smile")
But I can can now have newer version of modules and have that program work, older version that some programs need (mqtt being one that has broken things with v2) and it still works.
All while the OS doesn't care and can get updating what it (Debian) or RPiOS deam needs updating without altering my programs.
A lot of language are setup to do this without anyone really knowing. It just does it in the background as part of the IDE.
This helps because the OS itself has python files that you may update, override and hence break. (It's Debian enforcing this, not so much Python itself, they just created a method to do it after the many many complaints that much of python, pip and system modules couldn't be updated.)
You can disable it on Bookworm with a simple config entry and be on your merry way, perhaps breaking the system, but you are as before in the older OSs.
You can allow it to use the system modules, just a simple override when creating it, or editing a text file if already created so you have flexibility, but you can also install newer modules that you will override the system one but still not break the OS or any other python program on your system.
One big advantage is you could setup your robot with all the modules you need and not trip over the OS not worry about paths and have it working.
Then you think you want to mutex it as they have with i2c? (it's next.to that int he code).
Then if you duplicate that venv activate that one, rather than the working one, you can update modules, downgrade modules, tweak modules and mess with the modules trying things out without effecting the other venvs or the OS with fafy paths that are not working.
If it doesn't work, just delete it, fire up a new one.
It's a big safety net, a few thing needed fixing at the start of PiOS Bookworm but the gpio seems to be fixed (the module version was updated) now so the system wide one doesn't need to be used.
Your problem with updating the robot to Bookworm will actually the kernel and the way Bookworm uses gpio.
This has rendered most older gpio modules obsolete in one go.
So pigpio will not be used, and there will be a rewrite to lgpio or similar.
As a thought, pigpio, which you are using under the hood currently, has an spi bit banging method? Check out Joan's website
It's not venvs causing the problem.with Bookworm.
As for Thonny, they have in their changlogs path stuff in newer versions there has been quite a lot of updates from a program tweak to work on the Pi and then tweak to work well for primary school children.
I think version is in testing now.
Thonny used to run it's own Python version built in, in its vertual setup.
Maybe there is a drop down in the setting for paths or Python versions.
Hope that make some sort of sense and yes we all grumbled back in September too when it was forced upon us
But I can can now have newer version of modules and have that program work, older version that some programs need (mqtt being one that has broken things with v2) and it still works.
All while the OS doesn't care and can get updating what it (Debian) or RPiOS deam needs updating without altering my programs.
A lot of language are setup to do this without anyone really knowing. It just does it in the background as part of the IDE.
Statistics: Posted by bensimmo — Thu Jul 04, 2024 3:56 pm