File based configuration for the import system

--===============5539138498838313124==
Content-Type: multipart/alternative; boundary=001a1143fe2cd0f864053159ea02

--001a1143fe2cd0f864053159ea02
Content-Type: text/plain; charset=UTF-8

This isn't a fully thought out idea, but I figured it was worth posting
here as a potentially improved motivation for the interpreter bootstrapping
improvements proposed in PEP 432.

Currently, the proposed motivation there is for a system Python executable
that has different defaults from the normal CPython runtime:
https://www.python.org/dev/peps/pep-0432/#a-system-python-executable

It turns out that isn't a particularly compelling motivation for the degree
of change proposed, since Christian Heimes was able to implement the -I
switch for isolated mode without too much hassle, and you can fairly easily
provide a wrapper script that implicitly sets -I for all invocations.

For me though, one of the other motivations behind the proposed changes in
PEP 432 is getting to replace the current sys.path calculation code in
getpath.c and getpathp.c with Python code in importlib._bootstrap or
(depending on boot sequence details) importlib._bootstrap_external.

Once we did that, there would be a range of ideas (like allowing additional
path handling customisations in venv configuration files) that become
significantly more feasible to implement and maintain.

So, does that sound reasonable to folks as a revised primary motivation for
that PEP: moving the default sys.path calculation code to Python for ease
of reuse across implementations, and for ease of maintenance and
enhancement within CPython itself?

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia

--001a1143fe2cd0f864053159ea02
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>This isn&#39;t a fully thought out idea, but I figure=
d it was worth posting here as a potentially improved motivation for the in=
terpreter bootstrapping improvements proposed in PEP 432.<br><br></div>Curr=
ently, the proposed motivation there is for a system Python executable that=
 has different defaults from the normal CPython runtime: <a href=3D"https:/=
/www.python.org/dev/peps/pep-0432/#a-system-python-executable">https://www.=
python.org/dev/peps/pep-0432/#a-system-python-executable</a><br><div><br></=
div><div>It turns out that isn&#39;t a particularly compelling motivation f=
or the degree of change proposed, since Christian Heimes was able to implem=
ent the -I switch for isolated mode without too much hassle, and you can fa=
irly easily provide a wrapper script that implicitly sets -I for all invoca=
tions.<br><br></div><div>For me though, one of the other motivations behind=
 the proposed changes in PEP 432 is getting to replace the current sys.path=
 calculation code in getpath.c and getpathp.c with Python code in importlib=
._bootstrap or (depending on boot sequence details) importlib._bootstrap_ex=
ternal.<br><br></div><div>Once we did that, there would be a range of ideas=
 (like allowing additional path handling customisations in venv configurati=
on files) that become significantly more feasible to implement and maintain=
.<br><br></div><div>So, does that sound reasonable to folks as a revised pr=
imary motivation for that PEP: moving the default sys.path calculation code=
 to Python for ease of reuse across implementations, and for ease of mainte=
nance and enhancement within CPython itself?<br><br></div><div>Cheers,<br><=
/div><div>Nick.<br clear=3D"all"></div><div><div><br>-- <br><div class=3D"g=
mail_signature">Nick Coghlan=C2=A0=C2=A0 |=C2=A0=C2=A0 <a href=3D"mailto:nc=
[email protected]" target=3D"_blank">[email protected]</a>=C2=A0=C2=A0 |=C2=
=A0=C2=A0 Brisbane, Australia</div>
</div></div></div>

--001a1143fe2cd0f864053159ea02--

--===============5539138498838313124==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig

--===============5539138498838313124==--