On 21/03/2012 9:45 AM, R. David Murray wrote:
> On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond<skippy.hammond at gmail.com> wrote:
>> On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
>>> I asked a question about this on IRC, to which the response was that
>>> there were two main reasons to install python in c:\pythonxy:
>>>
>>> 1 - issues due to spaces ('Program Files') or non-ascii characters in
>>> the path ('Fișiere Program' on a Romanian windows). These issues are
>>> supposed to be fixed by now (?).
>>> 2 - issues due to permissions - installing python / packages in
>>> %programfiles% may require administrator rights.
>>
>> Apart from personal preference (ie, I prefer the status quo here), the
>> second issue is a bit of a killer. Even an administrator can not write
>> to Program Files unless they are using an "elevated" process (ie,
>> explicitly use "Run as Administrator" and confirm the prompt.
>>
>> This means that any installer wanting to write .py files into the Python
>> install must be elevated, and any Python process wanting to generate
>> .pyc files must also be elevated. So even if an installer does arrange
>> elevation, unless that installer also compiles all .pyc and .pyo files
>> at install time, Python would fail to generate the .pyc files on first
>> use. While Python will probably fail silently and still continue to
>> work, it will have a significant performance impact.
>
> So windows requires admin privileges to install to Program Files, but
> not to install to '/'? How novel. (You can perhaps tell that I'm
> not a windoows user). My understanding, though, is that Python
> does make a distinction between a system install of Python and
> a per-user one, so I don't think your objection really applies.
I think it does. Consider I've installed Python as a "system install".
Now I want to install some other package - ideally that installer will
request elevation - all well and good - the .py files are installed.
However, next time I want to run Python, it will fail to generate the
.pyc files - even though I'm an administrator. I would need to
explicitly tell Python to execute "as administrator" (or run it from an
already elevated command-prompt) to have things work as expected. Thus,
the "usual" case would be that Python is unable to update any files in
its install directory.
If Python installed for a single user didn't install into Program Files
(which it probably couldn't do without an administrator providing
credentials anyway) then it wouldn't be a problem - but then we have
multiple possible default install locations, which sounds like more
trouble than it is worth...
> That said, there is an open bug in the tracker about the insecurity
> of a system install of python (exactly that the files are writable
> by anyone). So that would have to be solved first. I'd say this
> is definitely a separate issue from Van's discussion, and the *only*
> reason one might want to tie them together at all is "well, we're
> changing the directory layout anyway".
Agreed.
Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4