Fwd: Installation hell

[Chris Angelico]

On Tue, 20 Dec 2022 at 10:01, Thomas Passin <list1 at tompassin.net> wrote:
>
> On 12/19/2022 5:16 PM, Chris Angelico wrote:
> > On Tue, 20 Dec 2022 at 09:12, Thomas Passin <list1 at tompassin.net> wrote:
> >> FWIW, I once set up a Python installation so that it could run from a
> >> USB stick (Windows only).  My launcher was a batch file that contained
> >> the following:
> >>
> >> @echo off
> >> setlocal
> >> : Find effective drive for this file.
> >> set ed=%~d0
> >> path %ed%\python37\Scripts;%ed%\python37;%PATH%
> >> set PYTHONUSERBASE=%ed%\user\python
> >> set HOME=%ed%\user\python
> >> call python %*
> >> endlocal
> >>
> >
> > So much easier to do on a Unix-like system, where you don't need to
> > concern yourself with "effective drive" and can simply use relative
> > paths. I know we're not here to bash Windows, but... drive letters
> > really need to just die already.
>
> Considering that this was for a removable drive, the launcher needed to
> know its own location, which might change from one instance to another.
> If you look at the code above, you won't find an obvious drive letter.
> You would need to do the equivalent on Linux. The Windows drive letter
> is just not relevant here.

The only thing that's relevant is the *path*. Everything can be made
relative to a single directory. On Unix-like systems, any relative
path can be made absolute with reference to a single directory - most
commonly the current working directory, of which there is precisely
one. On Windows, there is the current working directory, plus
twenty-six ADDITIONAL reference directories, plus a current drive (I'm
not certain whether "current working directory" is the same as
"current drive + current directory on that drive", so maybe there's
one fewer than this).

If you create a Python virtual environment without symlinks (eg
"python3 -m venv env --copies"), you can run Python scripts using that
environment simply by invoking the corresponding Python interpreter,
regardless of the actual path. Trivially easy, because it's simply
relative paths.

On Tue, 20 Dec 2022 at 10:03, Grant Edwards <grant.b.edwards at gmail.com> wrote:
>
> On 2022-12-19, Chris Angelico <rosuav at gmail.com> wrote:
>
> > So much easier to do on a Unix-like system, where you don't need to
> > concern yourself with "effective drive" and can simply use relative
> > paths. I know we're not here to bash Windows, but... drive letters
> > really need to just die already.
>
> They needed to "die already" 40 years ago. I was a Unix user before
> MS-DOS came out, and I was rather stunned by the whole drive letter
> thing. It seemed like such a giant step backwards. I figured that once
> hard drives became common, drive letters would die. Nope, they're
> still failing strong!

They feel like part of an old style of concrete identifiers, like
working with direct memory addresses (as opposed to virtual memory
pages), until you realise that even MS-DOS had a special hack that let
a single physical drive behave as both A: and B: with system-provided
prompts "please insert disk for drive A/B" when needed. And with the
SUBST and JOIN commands, you could - again, even in MS-DOS - mount
directories as drives or drives as directories. (I don't remember what
happened if you tried to use both at once to have a directory appear
in a different location - the equivalent of a bind mount. Might have
worked.) People could have destroyed drive letters by just always
turning them into directories, and then comfortably moving to a
Unix-like mount system, but since that didn't happen, generations of
Windows users have grown up with the expectation that drive letters
are a thing.

And that leads to myriad problems. Until Steve Dower got involved with
the Python installers, there were periodic issues resulting from
certain combinations of (a) installing Python somewhere other than the
C: drive, (b) using pip from somewhere other than the C: drive to
install packages, and (c) attempting to use those packages from
somewhere other than C:. I don't remember exactly what the solutions
were (I want to say that "use explicit paths" was part of it, but this
was a while ago and my memory of other people's problems isn't the
greatest), but it was often a mess.

Chrsia