The snowy days here have been so pretty, the snow contrasting with the
darkness of the piñons and junipers and the black basalt.
The light fluffy crystals sparkle in a rainbow of colors when they
catch the sunlight at the right angle, but I've been unable to catch
that effect in a photo.
We've had some unusual holiday visitors, too, culminating in this
morning's visit from a huge bull elk.
Dave came down to make coffee and saw the elk in the garden right next
to the window. But by the time I saw him, he was farther out in the
yard. And my DSLR batteries were dead, so I grabbed the point-and-shoot
and got what I could through the window.
Fortunately for my photography the elk wasn't going anywhere in any hurry.
He has an injured leg, and was limping badly.
He slowly made his way down the hill and into the neighbors' yard.
I hope he returns. Even with a limp that bad, an elk that size
has no predators in White Rock, so as long as he stays off the nearby
San Ildefonso reservation (where hunting is allowed) and manages to
find enough food, he should be all right. I'm tempted to buy some
hay to leave out for him.
Some of the sunsets have been pretty nice, too.
A few more photos.
[ 19:48 Jan 08, 2017
More photo |
permalink to this entry |
Python's installation tool, pip, has some problems on Debian.
The obvious way to use pip is as root:
sudo pip install packagename.
If you hang out in Python groups at all, you'll quickly find that this
is strongly frowned upon. It can lead to your pip-installed packages
intermingling with the ones installed by Debian's apt-get,
possibly causing problems during apt system updates.
The second most obvious way, as you'll see if you read pip's man page,
pip --user install packagename.
This installs the package with only user permissions, not root,
under a directory called ~/.local. Python automatically checks
.local as part of its PYTHONPATH, and you can add ~/.local/bin to
your PATH, so this makes everything transparent.
Or so I thought until recently, when I discovered that
pip install --user ignores system-installed packages
when it's calculating its dependencies, so you could end up with a
bunch of incompatible versions of packages installed. Plus it takes
forever to re-download and re-install dependencies you already had.
Pip has a clear page describing
pip --user is supposed to work, and that isn't what it's doing.
So I filed
pip bug 4222;
but since pip has 687 open bugs filed against it, I'm not terrifically
hopeful of that getting fixed any time soon. So I needed a workaround.
Use virtualenv instead of --user
Fortunately, it turned out that pip install works correctly in a
virtualenv if you include the --system-site-packages option.
I had thought virtualenvs were for testing, but quite a few people
on #python said they used virtualenvs all the time, as part of their
normal runtime environments. (Maybe due to pip's deficiencies?)
I had heard people speak deprecatingly of --user in favor of
virtualenvs but was never clear why; maybe this is why.
So, what I needed was to set up a virtualenv that I can keep around
all the time and use by default every time I log in. I called it
~/.pythonenv when I created it:
virtualenv --system-site-packages $HOME/.pythonenv
Normally, the next thing you do after creating a virtualenv is to
source a script called bin/activate inside the venv.
That sets up your PATH, PYTHONPATH and a bunch of other variables
so the venv will be used in all the right ways. But activate
also changes your prompt, which I didn't want in my normal runtime
environment. So I stuck this in my .zlogin file:
VIRTUAL_ENV_DISABLE_PROMPT=1 source $HOME/.pythonenv/bin/activate
Now I'll activate the venv once, when I log in (and once in every xterm
window since I set XTerm*loginShell: true in my .Xdefaults.
I see my normal prompt, I can use the normal Debian-installed Python
packages, and I can install additional PyPI packages with
pip install packagename (no --user, no sudo).
[ 11:37 Jan 08, 2017
permalink to this entry |