This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author steve.dower
Recipients FFY00, christian.heimes, frenzy, hroncok, jaraco, lemburg, petr.viktorin, steve.dower
Date 2021-05-05.20:44:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1620247452.97.0.872757842501.issue43976@roundup.psfhosted.org>
In-reply-to
Content
>> The best option for restricting the import while still having it be a Python
>> import is to find the file (if it's present in the expected location under
>> sys.whatever), and then use importlib to import it:
>> https://docs.python.org/3/library/importlib.html#importing-a-source-file-directly
>
> Right, though that requires also a new import, importlib, which may not be
> optimal. Considering that this module is meant to be private and basically all
> other private importable parts of Python suffer from the same issue, I am
> finding it hard to justify. If there's enough consensus that this approach would
> be better, I am more than happy to change the implementation.

Another alternative would be to convert sysconfig into a directory and make the vendor patch a submodule. That's _very slightly_ more impactful for the unpatched case, but only really for scenarios where people are trying to do things they shouldn't. Or we can include the file in all distros and import it earlier (before taking environment variables, etc. into account).

In my opinion, the security implications alone suggest we shouldn't be importing this by name without knowing where it is coming from.

>> I'd rather not have a new option here, I would much prefer "-S" in this
>> context to mean "run Python with only core libraries" and "-s" to mean "run
>> Python with only core and distro libraries" (and neither to mean "run Python
>> with core, distro and user libraries").
>
> I don't think having an option to start Python with only the vendor modules
> would be *necessary*, though it would certainly be helpful. Among other things,
> it would be super helpful to be able to tell users to run Python with the -D
> (made up) option to isolate issues with the vendor modules and the user Python
> environment.

But the user can already exclude their user-installed packages with -s, right? It's the site-installed packages that would require -S, but that also excludes vendor modules.

Why do we encourage users to install site-wide packages using pip? Why is it such an important scenario for a distro-provided Python to be able to modify its global install using non-distro-provided tools and non-distro-provided packages? What's wrong with saying "install for --user", or else "apt install some-different-python-bundle" first and use that?

(To be clear, I'm framing these as confrontational questions to help my understanding. I'm totally willing to accept an answer of "just because", provided whoever is giving that answer actually "owns" dealing with the fallout.)
History
Date User Action Args
2021-05-05 20:44:13steve.dowersetrecipients: + steve.dower, lemburg, jaraco, christian.heimes, petr.viktorin, hroncok, frenzy, FFY00
2021-05-05 20:44:12steve.dowersetmessageid: <1620247452.97.0.872757842501.issue43976@roundup.psfhosted.org>
2021-05-05 20:44:12steve.dowerlinkissue43976 messages
2021-05-05 20:44:12steve.dowercreate