Steve Dower added the comment:
The support is in and the option remains named applocal.
Hopefully this (and the ZIP file version, which will include the preconfigured
pyvenv.cfg) will help with app distributions, though I'm still open to make
changes if it doesn't.
--
resolution: -
Roundup Robot added the comment:
New changeset 620a247b4960 by Steve Dower in branch 'default':
Issue #23955: Add pyvenv.cfg option to suppress registry/environment lookup for
generating sys.path.
https://hg.python.org/cpython/rev/620a247b4960
--
nosy: +python-dev
Steve Dower added the comment:
Any further comments/bikeshedding on the applocal parameter? I still need to do
some docs, but I want the basic design agreed upon first.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23955
Nick Coghlan added the comment:
Issue 23857 was the one where I thought there might be an overlap with a design
consideration on Linux (related to coming up with a conventional for
backporting PEP 476 as a CPython redistributor).
However, I've now suggested a different path forward there,
Steve Dower added the comment:
Added a patch that:
* adds the applocal option to pyvenv.cfg
* updates the docs to describe how pyvenv.cfg (home and applocal) affect
sys.path
* puts a default pyvenv.cfg in the ZIP distribution
* adds significantly more buffer overflow protection to getpathp.c
*
Steve Dower added the comment:
Having looked at the implementation, the easiest way to do this will be to add
an applocal = true option to pyvenv.cfg, which would behave identically to
setting %PYTHONHOME% to the directory containing the config before launch.
I wanted to support relative
Thomas Kluyver added the comment:
Would that option be the only thing that needs to be set to make Python
app-local? I'm not familiar with what lives in pyvenv.cfg.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23955
Steve Dower added the comment:
None of the other options really have much use in this case, since they're
mostly about how to combine multiple environments rather than excluding
implicit ones.
Setting PYTHONHOME to the current directory certainly seems to be enough
AFAICT, at least for
Paul Moore added the comment:
As described. this seems to be a Windows-only feature (it's replacing a
registry lookup with a config file alongside the Python DLL).
So I'm not sure I understand Nick's comment - Nick, are you suggesting this
should be a cross-platform feature? If so, what's the
Nick Coghlan added the comment:
Treating local Python as a special-case of venv sounds like a good approach,
then (especially as it currently seems plausible we'll end up going for
environment variable based approach to the downstream PEP 476 backport)
--
Steve Dower added the comment:
I'm leaning towards clarifying/fixing the behavior of the venv config, since
it's most of the way there for what I care about. Adding another option for
applocal may be needed, but possibly not, in which case defining how relative
paths are handled would be
Nick Coghlan added the comment:
If we're adding a static startup configuration file, then yes, I believe that
should be a cross-platform feature, not something Windows specific, as it's a
major change to our configuration philosophy. (I think it's a *necessary*
change, but it's also a
Nick Coghlan added the comment:
I'd actually like a python.ini file defined as a Python 3.5 feature in order to
provide a better backporting story for the PEP 476 certificate changes in
downstream long term support releases of Python 2.7.
So +1 in principle, but I'd like to see this written
Thomas Kluyver added the comment:
Relative paths would be nice for Pynsist - I would prefer to create the config
file at build time and then install it along with the other files. If it needed
absolute paths, then the installer would have to write the config file after
the user selects the
Changes by Thomas Kluyver tak...@gmail.com:
--
nosy: +takluyver
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23955
___
___
Python-bugs-list
Steve Dower added the comment:
I could reuse the venv config file but it would need a new property to forcibly
use the 'home' value regardless of whether '$home\Lib\os.py' exists (in case
the stdlib is zipped) and to make it relative to the file's path rather than
the user's current
Steve Dower added the comment:
Arguably we should be making 'home' in pyvenv.cfg relative to the pyvenv.cfg
file's directory anyway... AFAIK it's always generated as an absolute path, but
I see no good reason to prevent people from manually configuring a relative
path here.
--
Éric Araujo added the comment:
Hm, could you reuse the venv config file with use-site-packages=true?
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23955
___
New submission from Steve Dower:
When Python starts running we (getpathp.c) looks in the registry for its
library directory. To avoid this, you can set PYTHONPATH and PYTHONHOME
environment variables, but this isn't always easy if you've copied Python into
your app's directory.
We should
19 matches
Mail list logo
