On 2/3/2016 12:15 AM, Alexander Walters wrote:
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.
Me too. My opinions follow, some might call them arguments, strong or weak, some might call them foolishness.
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.
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.
Portability requires not using the registry, so I agree with Alexander there.
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).
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".
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 slashdot http://slashdot.org/firehose.pl?op=view&id=80569101 for more details on the lack of a "current working directory" concept in Windows GUI programs.
The path to Dropbox folders is different for everyone, even the drive letter can be different.
So here are my preferences for CPython:
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.
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.
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.
4) A script could be provided to add the python that executed the script to the PATH, with an option to remove it.
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.
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.
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.
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.