[Python-ideas] Python Environment Initialization Scripts

[Nick Coghlan]

On Sun, Jul 29, 2012 at 3:22 PM, James William Pye <x at jwp.io> wrote:
> On Jul 28, 2012, at 8:17 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
>> That's where PEP 370 comes in.  Stick your sitecustomize.py into
>> ~/.local/lib/pythonX.Y/site-packages.  Then it only applies when
>> python is run as you.
>
> But it's not desirable for it to be limited one user...
>
> The situation is that the meta_path hook is provided in a package that is depended on
> by other packages that contain modules that are importable by the hook.
>
> It doesn't seem particularly appropriate to me for a given *package* to be fiddling with the
> system administrator's sitecustomize or the user's sitecustomize. No?
>
> Now, that's not to say that I'm unwilling to be inappropriate. >8)

The short answer is that, no, a coherent proposal for application
specific preinitialisation hasn't been put forward as a PEP. The
slightly longer answer is that there are related problems in terms of
initialising debuggers, warnings, logging, faulthandler, coverage,
profiling, etc, during development where it would be incredibly
convenient to be able to execute a short snippet of Python code prior
to execution.

See http://bugs.python.org/issue14803 (I'm nervous about the security
implications of a PYTHONRUNFIRST environment variable that is enabled
by default, but the idea of a -C option doesn't pose any such
concerns)

In general though, messing with process global state (including the
import system) implicitly is just *not cool*. It leads to applications
that have a dependency on a particular tool being present, but don't
actually make sure that it is available. Thus you end up with manual
instructions that say "before running this script, make sure
infrastructure X is in place to automagically take care of things I
should be doing myself".

Cheers,
Nick.


-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia