<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<div class="moz-cite-prefix">On 2/3/2016 12:15 AM, Alexander Walters
wrote:<br>
</div>
<blockquote cite="mid:56B1B73C.1030204@sdamon.com" type="cite">On a
very personal note (like the rest of this wasn't my personal
issues with possibly making my life slightly more difficult), I
would much rather see python stop touching the registry all
together - but I have no strong argument for that.
</blockquote>
<br>
Me too. My opinions follow, some might call them arguments, strong
or weak, some might call them foolishness.<br>
<br>
I've been setting up a collection of tools and programs on Dropbox
for far-flung project team members (users, not programmers) to
share. It is nearly impossible to install a typical Windows program
on Dropbox, because the installation information is partly in the
installed directory structure, and partly in the registry. Exporting
registry info from the machine that does the install to other
machines is hard because other users have different paths to
Dropbox. OK, for commercial software, installing to Dropbox probably
violates some of the licensing, forcing each user to buy/install,
but FOSS or in-house software doesn't have such restrictions: but
still, most of it wants to use the registry, and Windows almost, but
doesn't quite, force it to.<br>
<br>
Portable software exists, but often is 3rd party hacks of popular
FOSS rather than being directly supported by the FOSS development
team. Python falls into this category. Happily, I recently found
WinPython Zero, which hacks it (somehow) to work portably, and I've
deployed it successfully on Dropbox. I'd rather Python were portable
on its own, without hacks.<br>
<br>
Portability requires not using the registry, so I agree with
Alexander there.<br>
<br>
Portability, as "Windows portable software" is generally defined, is
focused on moving programs and data around on a flash drive, from
one computer to another, and is focused on single-user, any
(Windows) machine (with sufficient specs).<br>
<br>
That doesn't quite fit the Dropbox environment. Most portable
software reintroduces the idea of storing configuration information
in the program folder, which is OK for "project" configuration info,
done once, by one person, but not for "personal preferences".<br>
<br>
The other thing Windows GUI lost is the concept of "current working
directory", which hit me hard when I first started trying to set up
project working areas on Dropbox. Many Windows programs want to run
only one copy of themselves, in one Window, with one set of
settings, and one "Start In" directory (which generally defaults to
.... the program directory, or sometimes to "My Documents". This is
why I went looking for a portable Python (and other portable
things), and I finally realized that I was "fighting city hall" in
trying to get an environment set up that was usable for the various
teams (of users, not developers). Writeup at <a
href="http://slashdot.org/firehose.pl?op=view&id=80569101">slashdot</a>
for more details on the lack of a "current working directory"
concept in Windows GUI programs.<br>
<br>
The path to Dropbox folders is different for everyone, even the
drive letter can be different.<br>
<br>
So here are my preferences for CPython:<br>
<br>
1) It would be best CPython itself were fully portable. That
wherever you point the installer, it lives there, and if somehow you
happen to execute it from that directory, it would use its
invocation path as the basis for finding the rest of the installed
pieces.<br>
<br>
2) A script could be provided that sets the association for .py and
the corresponding ftype to point to the python that executed the
script... and which has a parameter to clear that back out, too.
This would be to allow users to set a particular python for
convenient script execution, since Windows does the association
thing, instead of using #! lines.<br>
<br>
3) A script could be provided (maybe the one Alexander referred to)
that sets the registry so that the "apparently one true System
Python" points to the python that executed the script... and which
has a parameter to clear that back out, too. This would be for
compatible transition to the new registry-free Python versions for
packages that have weird installers (such as Alexander alluded to).
But with the registry-free Python available, those packages would
hopefully see the future is registry free, and avoid requiring
registry data to do installs.<br>
<br>
4) A script could be provided to add the python that executed the
script to the PATH, with an option to remove it.<br>
<br>
5) A script could be provided to add the python that executed the
script to the launcher .ini file, with an option to remove it.<br>
<br>
6) A script could be provided to add the python that executed it to
the Start menu, and/or Desktop icons, with an option to remove them.<br>
<br>
Maybe scripts 2-6 are all the same one, with different options (or
different invocation shortcuts for the clicky folk). Not everyone
would probably need all the scripts, but none of them would be
particularly large, such that they would be burdensome for others to
ignore.<br>
<br>
Such a collection of scripts would allow folks to achieve various
levels of integration with Windows "conveniences", without requiring
it. The portability would allow Python to be installed on Dropbox or
a network share, and used from there without requiring every team
member to do all the individual installs of the packages needed for
a project.<br>
</body>
</html>