2:27 PM
Ah, you remind me the first time I try to upgrade my Rpi1 or Rpi2 from default python 3.5.3 to python 3.7.3. It took me about 3 hours before I gave up. I knew I did not have the prerequisite linux knowledge and tools, to locate the problem. I made a mess of the directories. I still do not know what are "alias" directories, and I am not keen to learn, because the new buster GUI tools including the new install/upgrade tools solve almost all my install problems.
I still remember trying "curb", "NMB" (not sure if I spell correctly) and a couple of other
installation tools. The problem is the following:
Important advice to newbies
(1) When your package is supposed to run in python 2.7, then you should almost always use "pip", which means by default "pip2". If you wrongly use "pip3", the package is installed in a directory for python3. Often you can try to "pip" again to install the package in a directory for python 2.7. Now the default "path" command would be changed to python3 to python 2 directory.
But if you are using python3 now and python2 some other time, then no one will automatically change the path config files for you, with the result of a big mess.
What I said is the "Tower of Barbel" is that some python packages are ported from Ubantu or other linux variants, by so many hackers in different places at different times, and they might have left their gitHub package unsupported, and other new hackers come along and "fork" new versions of the old package.
The most disgusting or criminal thing is that some hackers (they call themselves "developers") when forking a new version of the old package, do not following the standard of moving the directories for pip/pip3 etc, with the following horrible result:
In some rare cases, when you first wrongly use "pip3", find it does not work, and try your luck using "pip", it is too late, because the auto config thing won't bother to take care of going back to pip2. The only solution I know, at least for me newbie, is the following.
When trying new things, always keep the working image as a backup, and make a test/work SD image to try the new things, and as you go smoothly, make work image #2 and move on, then #3 and move on etc. When you have trouble using say, work 15, them fall back to work 14, and still no luck, fall back further to #13. And if #13 ok, then make #14a and move on.
This is a general troubleshooting technique called "swapping" test/troubleshooting. Of course many people said it is just common sense, no big deal. But then I learn the following in a hard way: The difference between a pro and a non-pro is that a pro makes backup.
Bed time. Call it a day. See you tomorrow. PS - I found my old hx711 module proto board in the junk bin. Might try it tomorrow.