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
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 PEP is your best
bet.
Ch
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* defined) in the registry.
I'm
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 not familiar with the Windows
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 but
> write the same reg
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 subst
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 Python's registry use caus
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 that
> point alone, this sa
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 ad
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 th
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 (in much the same way th
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,
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\**'))
sys.path.extend(read_subkeys(fr'HKLM\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))
It seems like a b
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 spirit at least) that this
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 and zip to a "portable"
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, that's horrid but not reall
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 publicise better. People seem
u
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 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 stop touching the registry
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 t
...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 standa
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 ti
22 matches
Mail list logo
