Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 04:14, Thomas Passin <list1 at tompassin.net> wrote:
>
> On 12/19/2022 11:36 AM, Chris Angelico wrote:
> > On Tue, 20 Dec 2022 at 03:05, Thomas Passin <list1 at tompassin.net> wrote:
> >>
> >> That's not been my experience.  Windows installers for Python have
> >> worked well for me over many generations of Python releases.  It's Linux
> >> where I've found difficulties.  For example, if your distro's Python
> >> install didn't include tkinter (or even pip), how do you get it?  It's
> >> different for different Linux distros.  I generally have to use internet
> >> searches to find out.
> >
> > If you want to use your distro's Python and add more stuff to it
> > globally, then yes, it depends on your distro. This is not really a
> > surprise.
> >
> >> For another example, when you use pip to install a package, it sometimes
> >> suggests that you install a newer version of pip itself. Should you do
> >> that?  On Linux, probably not, because the distro will have modified pip
> >> so it puts things in distro-specific places. Yet there is no newer
> >> version of pip available through the distro's package manager.  Will
> >> anything bad happen if you don't update pip?  Who knows?
> >
> > Virtual environments work the same way regardless of distro, including
> > allowing you to install an upgraded pip.
>
> I have always disliked working with venvs and avoid it whenever
> possible.  But I suppose that's just me.
>

That's fine. You don't HAVE to use venvs - and in fact, I only use
them for a relatively small number of projects (eg those that get
deployed to Heroku - make a venv, match Python version to Heroku's
offering, and install packages into it, for maximum consistency).
There are a few ways to manage things:

1) Always use your package manager. Don't use pip at all.
2) Install pip from your package manager, but then do user
installations (~/.local).
3) Install venv from your package manager, use virtual environments everywhere.
4) Build Python from source, parallel to your system Python.
5) Some combination of the above.

As you saw from my tab-tab demo, I have a LOT of Pythons installed,
many of them alphas and betas. Right now, my 'python3' command is
3.12, but /usr/bin/python3 is the system Python (3.9.2) and has
packages managed by apt/dpkg. So when a system-installed script tries
to run, it finds the Python and packages that were curated by the
Debian folks; but if I, at the command line, type "python3
somescript.py", I get a newer Python with packages managed by pip.
Sometimes I'll install those with "sudo python3 -m pip install X", but
mostly without sudo, and they land in ~/.local. (Installing as root is
useful when I need other users to be able to run the script - it's a
pain to try to install something into the correct low-privilege user.)

You have options. There's nothing wrong with picking and choosing
according to what's convenient for you.

ChrisA