Hello list.

I'm moved my old Python27 installation from
f:\ProgramFiler\Python27 ( == 'ProgramFiles')
to
f:\gv\Python27

and now many 'scripts/*.exe' program fails
to start since the old path to 'Python.exe'
is wrong.

E.g. 'Scripts/pip2.exe' has the path
"f:\programfiler\python27\python.exe" hard-coded
inside it.

Is there a easy way to fix this w/o re-installing this
old Python?

--
--gv

Gisle Vanem <gvanem@yahoo.no> writes:
>and now many 'scripts/*.exe' program fails
>to start since the old path to 'Python.exe'
>is wrong.

(The following information was obtained by looking at one
Python installation under one Version of the Microsoft®
Windows operating system. If you use different versions,
this information might not apply.)

The old path is in all those *.pyc files from the
__pycache__ directories in the Python directory.
Maybe one can delete them all? Other files with the
path might be "default.cfc" and "vba_extract.py".

And you need to search and replace the old path under some
registry keys, such as keys the names of which start with

HKEY_CLASSES_ROOT\Python
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer
HKEY_CURRENT_USER\Software\Classes\Python
HKEY_CURRENT_USER\Software\Python

and possibly for other users (beneath CURRENT_USER)
if there are such other users.

One could also uninstall and reinstall Python, but maybe
then one needs to save one's own project files before
uninstalling, because Python might have stored some of them
in its own directory (where it was installed).

Gisle Vanem <gvanem@yahoo.no> writes:

> Hello list.
>
> I'm moved my old Python27 installation from
> f:\ProgramFiler\Python27 ( == 'ProgramFiles')
> to
> f:\gv\Python27
>
> and now many 'scripts/*.exe' program fails
> to start since the old path to 'Python.exe'
> is wrong.
>
> E.g. 'Scripts/pip2.exe' has the path
> "f:\programfiler\python27\python.exe" hard-coded
> inside it.
>
> Is there a easy way to fix this w/o re-installing this
> old Python?

Wouldn't it be great if it were portable by default?

Meredith Montgomery <mmontgomery@levado.to> writes:
>Wouldn't it be great if it were portable by default?

I think under Windows there is a division of software
suggested by Microsoft, a division of software into
executable code and data (data may change in time).

The executable code is supposed to rest under
"C:\Program Files" the contents of which cannot be
modified by user processes easily. Program configuration
can be stored below "AppData" in the user directory.
It is supposed to be more secure when executable code
cannot be modified easily by user processes.

So far, Python has decided to ignore this and install
everything under AppData as I understand it. So one
gets neither the security of "Program Files" nor the
possibility to move it to another directory easily.

On 2 Oct 2022 14:22:30 GMT, ram@zedat.fu-berlin.de (Stefan Ram) declaimed
the following:

> So far, Python has decided to ignore this and install
> everything under AppData as I understand it. So one
> gets neither the security of "Program Files" nor the
> possibility to move it to another directory easily.
>
Only if you install for single user... Install for ALL users MUST put
the executable/libraries into a public location (if still read-only).
Problem with putting Python in C:\Program Files\ is that installing (again
for all users) via pip requires admin privileges.

Much easier (at least with the installers I've used) is to override the
default install location and use something like C:\Pythonx.y\ (x.y being
version info).

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Meredith Montgomery <mmontgomery@levado.to> writes:
>>Wouldn't it be great if it were portable by default?
>
> I think under Windows there is a division of software
> suggested by Microsoft, a division of software into
> executable code and data (data may change in time).
>
> The executable code is supposed to rest under
> "C:\Program Files" the contents of which cannot be
> modified by user processes easily. Program configuration
> can be stored below "AppData" in the user directory.
> It is supposed to be more secure when executable code
> cannot be modified easily by user processes.
>
> So far, Python has decided to ignore this and install
> everything under AppData as I understand it. So one
> gets neither the security of "Program Files" nor the
> possibility to move it to another directory easily.

Interesting. I like portable things. You copy from one place to
another and it just runs. As it should. Things should be simple.

On 04/10/2022 14.10, Meredith Montgomery wrote:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>
>> Meredith Montgomery <mmontgomery@levado.to> writes:
>>> Wouldn't it be great if it were portable by default?
>>
>> I think under Windows there is a division of software
>> suggested by Microsoft, a division of software into
>> executable code and data (data may change in time).
>>
>> The executable code is supposed to rest under
>> "C:\Program Files" the contents of which cannot be
>> modified by user processes easily. Program configuration
>> can be stored below "AppData" in the user directory.
>> It is supposed to be more secure when executable code
>> cannot be modified easily by user processes.
>>
>> So far, Python has decided to ignore this and install
>> everything under AppData as I understand it. So one
>> gets neither the security of "Program Files" nor the
>> possibility to move it to another directory easily.
>
> Interesting. I like portable things. You copy from one place to

At which point we mention that this is exactly how Linux works. A 'zen'
of Linux applications and utilities has always been: "do one thing, and
do it well".

Then directory/file access controls aim to keep users in 'userland' and
away from 'system', and for folk who want more there are security
features such as apparmor which limit the types of usage of files (as
well as resisting external threats).

Extending this a little further: such philosophy enables Linux users to
more-easily install (and run) multiple versions of Python*, Firefox,
Chromium, etc, without resorting to containers or VMs.

* eg v2 and v3 installed concurrently, to possibly suit OP

> another and it just runs. As it should. Things should be simple.

+1
--
Regards,
=dn

On 2022-10-04 at 14:55:36 +1300,
dn <PythonList@DancesWithMice.info> wrote:

> On 04/10/2022 14.10, Meredith Montgomery wrote:
> > ram@zedat.fu-berlin.de (Stefan Ram) writes:
> >
> >> Meredith Montgomery <mmontgomery@levado.to> writes:
> >>> Wouldn't it be great if it were portable by default?
> >>
> >> I think under Windows there is a division of software
> >> suggested by Microsoft, a division of software into
> >> executable code and data (data may change in time).
> >>
> >> The executable code is supposed to rest under
> >> "C:\Program Files" the contents of which cannot be
> >> modified by user processes easily. Program configuration
> >> can be stored below "AppData" in the user directory.
> >> It is supposed to be more secure when executable code
> >> cannot be modified easily by user processes.
> >>
> >> So far, Python has decided to ignore this and install
> >> everything under AppData as I understand it. So one
> >> gets neither the security of "Program Files" nor the
> >> possibility to move it to another directory easily.
> >
> > Interesting. I like portable things. You copy from one place to
^
Copy what? That's the crux of it.

On vintage (1980s? 1990s? way before OS X, anyway) Mac OS, I could copy
an alias (Mac's version of a symbolic link) to a floppy disk, walk (IOW,
"transfer via sneaker net") that alias to another Mac on the network,
and open *the original file* from that other Mac. (I could even move
the file to another folder on the original Mac, but that didn't mean
much, because those old file systems were entirely flat (directories and
folders were an illusion maintained by the Finder).)

Permissions? We don't need no stinkin' permissions! ;-)

> > another and it just runs. As it should. Things should be simple.
>
> +1

I like simple, portable things, too. But this kind of simplicity
(applications looking in known locations for certain files) and this
kind of portability (allowing users to move those files) are at oods.
And that's before we consider security.

Also, [almost] by definition, Python virtual environments really blur
the lines between user, system, public, private, programs, and data.

On 4/10/22 10:49 pm, 2QdxY4RzWzUUiLuE@potatochowder.com wrote:
> (I could even move
> the file to another folder on the original Mac, but that didn't mean
> much, because those old file systems were entirely flat (directories and
> folders were an illusion maintained by the Finder)

That was only true in the very early days. A proper hierarchical
file system was available as soon as hard disks became common
(around the Mac II era I think?)

However, internally each file on a volume was identified by a
File ID (something a bit like an inode number) and that was
stored in the alias and used as the first means of finding the
file. There was also a pathname stored in the alias, but that
was only used as a backup in case the file couldn't be found
using the File ID.

So a Mac alias was in some ways more powerful than a
symlink, but in other ways less -- e.g. there was no equivalent
to a relative symlink. Also aliases are more like a Windows
shortcut in that they aren't resolved automatically in the
kernel -- programs need to be aware of them and take explicit
action to resolve them.

Things are even more confusing in MacOSX, which has both
aliases *and* symlinks, they behave differently, and the Finder
doesn't tell you which you're looking at. :-(

--
Greg