First:
These are all good replies and I am learning a lot.
Second:
Yes, this is a GoPiGo robot running GoPiGo O/S (Buster), with Python 3.7.n.
The Python 2 libraries are there for backwards compatibility with some of the older utilities which are not really relevant to this discussion.
Third:
I, with my colleague cyclicalobsessive on the Dexter Forms, uncovered Dexter's generalized mutex class that solves many problems, and he was the first that suggested explicitly placing the path in my code - which always works.
However, I am uncomfortable with that solution, especially within an IDE that seems to have, (and enforce!), its own version of reality.
Here's the problem I have with that:
I am trying to interface a Waveshare e-Paper display to the robot as a secondary display that can report the status and/or important information about the robot while it's running. Both use SPI interface 1 to communicate. (Note that SPI interface zero is explicitly reserved for system HAT ID, is forbidden to be used, and would require considerable cut-and-jumper modification of the PC boards to implement, so I won't.
There are two different code bases that use SPI for communication in this case:
* The Dexter robot code uses SPI interface 1 and CS-1 to communicate with the controller board.
* The Waveshare display code uses SPI interface 1 and CS-0 to communicate with the e-Paper display.
Theoretically, they can coexist. However, neither board monitors the other's CS so they can - and do - transmit at the same time causing collisions and the robot's controller board goes brain-dead. (Note this is just a theory as I do not have the kind of sophisticated test equipment to precisely monitor both of the SPI channels at the same time. However, since it's the most likely suspect, I'm working that path first.)
The obvious solution is to modify both the Dexter and Waveshare code to use a mutex to monitor the SPI transfers and arbitrate between them. That is the forum thread noted above.
To modify the Dexter code, I need to isolate the libraries, (easygopigo, easysensors, and gopigo), into a test directory and ensure all the calls to these libraries use these "test" libraries exclusively so they are under my strict experimental control. I also want to divert the Waveshare libraries to this test library directory so I can isolate and experiment with them as well. In essence, I want to isolate both sets of libraries so I can experiment with them in a controlled manner.
Especially since the IDE's have their own version of reality that seems to have no relationship to the reality shared by anywhere else in the operating system, I cannot guarantee that any one piece of code running in the IDE, even if called or included by something with an explicit path, will use the path I specify, unless I go through the entire Waveshare libraries, manually follow every possible path, and modify every possible library file to include my explicit path.
Obviously, that increases the likelihood of mistakes and inadvertent bugs being introduced simply because I'm modifying things - need it or not. So I don't want to do that.
So, the obvious solution is to force the IDE to globally conform to my modified library path(s). And that is the problem. The IDE's live in their own twisted sense of reality and I have no idea how to conform them to the reality faced by the rest of the operating system via the system path and/or python paths.
Virtual environments and/or containers.
(Note that this is off-topic, but since virtual environments keep coming up, I want to raise this question/issue.)
I have noticed that in virtually every question I post just about anywhere nowadays, the knee-jerk reaction is a virtual environment. In a manner similar to the browser writer's desire to lock everything behind a secure certificate paywall, need it or not, the current Python fad seems to be virtual environments. So much so that if I try to do anything in Bookworm, I am compelled to use a virtual environment or add a silly and humiliating switch:
--yes_I'm_a_bloody_fool_and_want_to_thoroughly_bork_my_system_beyond_recognition.
(Note a simple --force, or a system-settable option would have sufficed.)
My opinion:
A virtual environment, like a virtual machine, is a TOOL, one of many, that can be used by the system designer or developer to accomplish a task.
You don't use a laptop as a hammer, nor do you use a pipe-wrench to do delicate neurosurgery on someone's brain - neither tool is appropriate for those particular jobs. Especially as there ARE better and more suitable tools.
There are, and will be, places where a virtual environment is the correct tool, and there are, and will be, places where a virtual environment isn't. And, don't you think it's' the province of the designer or system engineer to decide what's best for his system, based on his own years of knowledge and experience? And isn't it a bit arrogant to assume that "you" know more about his system's requirements than he does?
So, will someone please explain why the current trend in Python is that everyone must use a virtual environment, need it or not, suitable or not, even if it renders the project or application more complex and prone to bugs and mistakes?
I spent decades in the aerospace industry and - especially there - requirements are both rigid and possibly a matter of life-and-death, so I know about requirements. Even there, folks aren't arrogant about them, it's just the way it is as there's no room for mistakes in a spacecraft filled with hideously explosive fuel travelling at mach-17, or an aircraft full of passengers at 40,000 feet at mach 0.8. Even there, designers are given the latitude of experience to design whatever system they feel is the best implementation of a specific requirement. If you can get a Python virtual environment or a Docker container to meet the relevant MIL-STD, go right ahead!
However, as here, working with a simple robot, why does it seem that virtual environments are being forced down our throats? The biggest hindrance to porting the GoPiGo code and libraries to Bookworm is the new Python requirements for virtual environments that poke their grisly heads up in the most unexpected places, adding unnecessary complication and trouble to what should be a simple task.
This makes no sense to me and, (again IMHO), represents a level of arrogance seldom seen in any technical field in the fifty-some-odd years I've worked in it since graduating from college.
What say ye?
These are all good replies and I am learning a lot.
Second:
Yes, this is a GoPiGo robot running GoPiGo O/S (Buster), with Python 3.7.n.
The Python 2 libraries are there for backwards compatibility with some of the older utilities which are not really relevant to this discussion.
Third:
I, with my colleague cyclicalobsessive on the Dexter Forms, uncovered Dexter's generalized mutex class that solves many problems, and he was the first that suggested explicitly placing the path in my code - which always works.
However, I am uncomfortable with that solution, especially within an IDE that seems to have, (and enforce!), its own version of reality.
Here's the problem I have with that:
I am trying to interface a Waveshare e-Paper display to the robot as a secondary display that can report the status and/or important information about the robot while it's running. Both use SPI interface 1 to communicate. (Note that SPI interface zero is explicitly reserved for system HAT ID, is forbidden to be used, and would require considerable cut-and-jumper modification of the PC boards to implement, so I won't.
There are two different code bases that use SPI for communication in this case:
* The Dexter robot code uses SPI interface 1 and CS-1 to communicate with the controller board.
* The Waveshare display code uses SPI interface 1 and CS-0 to communicate with the e-Paper display.
Theoretically, they can coexist. However, neither board monitors the other's CS so they can - and do - transmit at the same time causing collisions and the robot's controller board goes brain-dead. (Note this is just a theory as I do not have the kind of sophisticated test equipment to precisely monitor both of the SPI channels at the same time. However, since it's the most likely suspect, I'm working that path first.)
The obvious solution is to modify both the Dexter and Waveshare code to use a mutex to monitor the SPI transfers and arbitrate between them. That is the forum thread noted above.
To modify the Dexter code, I need to isolate the libraries, (easygopigo, easysensors, and gopigo), into a test directory and ensure all the calls to these libraries use these "test" libraries exclusively so they are under my strict experimental control. I also want to divert the Waveshare libraries to this test library directory so I can isolate and experiment with them as well. In essence, I want to isolate both sets of libraries so I can experiment with them in a controlled manner.
Especially since the IDE's have their own version of reality that seems to have no relationship to the reality shared by anywhere else in the operating system, I cannot guarantee that any one piece of code running in the IDE, even if called or included by something with an explicit path, will use the path I specify, unless I go through the entire Waveshare libraries, manually follow every possible path, and modify every possible library file to include my explicit path.
Obviously, that increases the likelihood of mistakes and inadvertent bugs being introduced simply because I'm modifying things - need it or not. So I don't want to do that.
So, the obvious solution is to force the IDE to globally conform to my modified library path(s). And that is the problem. The IDE's live in their own twisted sense of reality and I have no idea how to conform them to the reality faced by the rest of the operating system via the system path and/or python paths.
Virtual environments and/or containers.
(Note that this is off-topic, but since virtual environments keep coming up, I want to raise this question/issue.)
I have noticed that in virtually every question I post just about anywhere nowadays, the knee-jerk reaction is a virtual environment. In a manner similar to the browser writer's desire to lock everything behind a secure certificate paywall, need it or not, the current Python fad seems to be virtual environments. So much so that if I try to do anything in Bookworm, I am compelled to use a virtual environment or add a silly and humiliating switch:
--yes_I'm_a_bloody_fool_and_want_to_thoroughly_bork_my_system_beyond_recognition.
(Note a simple --force, or a system-settable option would have sufficed.)
My opinion:
A virtual environment, like a virtual machine, is a TOOL, one of many, that can be used by the system designer or developer to accomplish a task.
You don't use a laptop as a hammer, nor do you use a pipe-wrench to do delicate neurosurgery on someone's brain - neither tool is appropriate for those particular jobs. Especially as there ARE better and more suitable tools.
There are, and will be, places where a virtual environment is the correct tool, and there are, and will be, places where a virtual environment isn't. And, don't you think it's' the province of the designer or system engineer to decide what's best for his system, based on his own years of knowledge and experience? And isn't it a bit arrogant to assume that "you" know more about his system's requirements than he does?
So, will someone please explain why the current trend in Python is that everyone must use a virtual environment, need it or not, suitable or not, even if it renders the project or application more complex and prone to bugs and mistakes?
I spent decades in the aerospace industry and - especially there - requirements are both rigid and possibly a matter of life-and-death, so I know about requirements. Even there, folks aren't arrogant about them, it's just the way it is as there's no room for mistakes in a spacecraft filled with hideously explosive fuel travelling at mach-17, or an aircraft full of passengers at 40,000 feet at mach 0.8. Even there, designers are given the latitude of experience to design whatever system they feel is the best implementation of a specific requirement. If you can get a Python virtual environment or a Docker container to meet the relevant MIL-STD, go right ahead!
However, as here, working with a simple robot, why does it seem that virtual environments are being forced down our throats? The biggest hindrance to porting the GoPiGo code and libraries to Bookworm is the new Python requirements for virtual environments that poke their grisly heads up in the most unexpected places, adding unnecessary complication and trouble to what should be a simple task.
This makes no sense to me and, (again IMHO), represents a level of arrogance seldom seen in any technical field in the fifty-some-odd years I've worked in it since graduating from college.
What say ye?
Statistics: Posted by jharris1993 — Thu Jul 04, 2024 9:38 am