Python • Re: DS18B20 / w1thermsensor

"this environment is externally managed".means you are executing the command in a terminal with the venv not activated.

I actually was executing the pip with the venv activated. I had created the venv without copying over the main package distribution. So I recreated it doing that copy-over and then the install succeeded. It gave a warning that the package had been installed in /home/pi/.local/bin and I should add that to my $PATH., which I did.

Strange (at least to this Linux noob) is that now my Python programs that use the sensor work WITHOUT having the venv activated. (???) It's like the venv was only needed for the install. Does that make sense?

I look in /home/pi/.local/bin and the only file there is: w1thermsensor, of type plain text, and here is what it contains:

Code:

#!/home/pi/Documents/HVAC/env/bin/python# -*- coding: utf-8 -*-import reimport sysfrom w1thermsensor.cli import cliif __name__ == '__main__':    sys.argv[0] = re.sub(r'(-script\.pyw|\.exe)?$', '', sys.argv[0])    sys.exit(cli())

I'm glad it works but sure don't understand it!

I don't know what this file is called (maybe you posted the name somewhere up there and I just did not look), but it is a python entry point script which wraps the actual execution of a python script with something akin to This has the effect of always using that virtual environment's python version, even if I have not "activated" the environment or messed with my path in any way.

If you edit that script from this:
I'm glad it works but sure don't understand it!
[/quote]

to this:
Then execute it from a terminal, it will show you what it is doing.

It's sort of like this. You have a project that does several things. Each of those things requires calling a script in some path where that code is found and takes some or several parameters to tell it to do one of a few different things.

So you create entry point scripts and place it in some "bin" folder. It could be /usr/bin if your thing was to be installed for all users to use, or your home's .loca/bin so only you can use it.

Now each entry point does a subset of what your project can do. Say you have some complex project where you'd use several different parameters for an inital setup, another for clean up, another for reset, another to stop it, etc. Instead of executing:

/path/project/venv/bin/activate
/path/project/script.py -op1 -z -blah blahblah

for option blahblah and

/path/project/venv/bin/activate
/path/project/script.py -op1 -z -blah blahblahblahblah

for option blahblahblahblah

You create entrypoints myproj_blahblah.py and myproj_blah_4 and put them in $PATH so you don't have to first activate the env, then call the entire path or even cd there first.

For a more accurately technical explanation of it, because I use some rather mundane non-nonsensical example, you can go here to find out how it really works https://packaging.python.org/en/latest/ ... ry-points/

Statistics: Posted by memjr — Sat Aug 03, 2024 4:59 pm

---