On 3 February 2016 at 15:15, Steve Dower wrote:
> Presented in PEP-like form here, but if feedback suggests
> just putting it in the docs I'm okay with that too.
We don't really have anywhere in the docs to track platform
integration topics like this, so an Informational
I am well aware of this. In the SO question I referenced, being the
first google hit related this this... that is the answer *I* gave. It
only works, in my experience, 60% of the time, and not with two biggie
packages (pywin32, for which you have to go to third parties to get the
wheel, which
...just when I thought I have solved the registry headaches I have been
dealing with...
I am not saying this proposal will make the registry situation worse,
but it may break my solution to the headaches Python's registry use
causes with some non-standard module installers (and even the
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
On 3 February 2016 at 09:50, Glenn Linderman wrote:
> 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
On 03Feb2016 1120, Alexander Walters wrote:
Uh its C:\Anaconda[2]\ for anyone running the installer with the
privileges to edit the registry... (It wont ask to elevate unless you
install for all users, and that's where all users will install). So on
that point alone, this saves nothing
On 03Feb2016 1851, eryk sun wrote:
On Wed, Feb 3, 2016 at 7:33 PM, Eric Snow wrote:
Just wanted to quickly point out another use of the WIndows registry
in Python: WindowsRegistryFinder [1]. This is an import "meta-path"
finder that locates modules declared (*not*
On Wed, Feb 3, 2016 at 7:33 PM, Eric Snow wrote:
> Just wanted to quickly point out another use of the WIndows registry
> in Python: WindowsRegistryFinder [1]. This is an import "meta-path"
> finder that locates modules declared (*not* defined) in the registry.
> I'm
On Tue, Feb 2, 2016 at 10:15 PM, Steve Dower wrote:
> I was throwing around some ideas with colleagues about how we detect Python
> installations on Windows from within Visual Studio, and it came up that
> there are many Python distros that install into different locations
On 03Feb2016 0015, Alexander Walters wrote:
I am not saying this proposal will make the registry situation worse,
but it may break my solution to the headaches Python's registry use
causes with some non-standard module installers (and even the standard
distutils exe installers, but that is being
On 03Feb2016 0923, eryk sun wrote:
On Wed, Feb 3, 2016 at 10:46 AM, Steve Dower wrote:
sys.path.extend(read_subkeys(fr'HKCU\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))
On 03Feb2016 0839, Paul Moore wrote:
On 3 February 2016 at 16:29, Steve Dower wrote:
Final point I want to reiterate - Python itself is essentially registry free
already in that it does not need registry settings to function.
That's something we should probably
On 3 February 2016 at 17:04, Steve Dower wrote:
> Rest of the email is spelling out how to create the scenario above, since I
> assume people won't believe it :)
>
> 1. Take Python 3.4.1, install it (Just for Me), zip up the stdlib into
> python34.zip and copy the binaries
On Wed, Feb 3, 2016 at 10:46 AM, Steve Dower wrote:
>
> sys.path.extend(read_subkeys(fr'HKCU\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))
> sys.path.extend(read_subkeys(fr'HKLM\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))
It seems like a bug (in
On 3 February 2016 at 16:46, Steve Dower wrote:
> So a few high-level observations:
>
> * any program can install anywhere on the machine and make its libraries
> available to a specific version of Python by creating a subkey under
> 'PythonCore\x.y\PythonPath'
Yeah,
On 3 February 2016 at 19:20, Alexander Walters wrote:
> Uh its C:\Anaconda[2]\ for anyone running the installer with the
> privileges to edit the registry... (It wont ask to elevate unless you
> install for all users, and that's where all users will install). So on
On 2/3/2016 11:17, Steve Dower wrote:
I know for PTVS manually adding a python environment to visual studio is
trivial - you fill in three locations, and its done. Just today I added
a python environment to my system that was not autodetected. It took
under a minute and almost no effort to
On 3 February 2016 at 16:29, Steve Dower wrote:
> Final point I want to reiterate - Python itself is essentially registry free
> already in that it does not need registry settings to function.
That's something we should probably publicise better. People seem
unaware of it
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
On 03Feb2016 0321, Paul Moore wrote:
> Some issues with this proposal:
>
> 1. I don't like the way it states that Python distributions "must" set
> keys. I'd rather that it were explicitly stated that a distribution
> which sets no registry keys is entirely valid (with the obvious
> implication
On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters
wrote:
> ...just when I thought I have solved the registry headaches I have been
> dealing with...
>
> I am not saying this proposal will make the registry situation worse, but
> it may break my solution to the headaches
I was throwing around some ideas with colleagues about how we detect
Python installations on Windows from within Visual Studio, and it came
up that there are many Python distros that install into different
locations but write the same registry entries. (I knew about this, of
course, but this
22 matches
Mail list logo