On 03Feb2016 0150, Glenn Linderman wrote:
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.
Python has been registry independent for a while if you set the
PYTHONHOME environment variable (and independent but potentially
unreliable even without this).
Most of the registry settings created on install are for supporting
upgrades, repairs and uninstallation, none of which matter in your case.
(Also many python-dev readers' cases, but there are a lot of users who
get into trouble very quickly without this level of management.)
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.
Agreed, and it already basically does this as mentioned above.
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.
You probably want the py.exe launcher here (though that relies on Python
being registered...), as it handles shebangs - even /usr/bin/env style.
A script such as what you're asking for would be possible, but not
something I want to be responsible for providing and maintaining.
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.
4-6 are basically the definition of an installer, and other installers
are also able to do this.
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.
Perhaps you really want a script to run the installer and then pip?
Final point I want to reiterate - Python itself is essentially registry
free already in that it does not need registry settings to function. The
current problems are:
1. other programs need to locate all available Pythons
2. there appears to only be one space to register your Python
3. this space is *sometimes* used by Python to locate itself and
installed packages
I want to fix problem 2 via documentation, and then look at the much
more difficult problem 3.
Cheers,
Steve
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
