Filipe Laíns <la...@riseup.net> added the comment: We cannot change how `sudo pip install` fundamentally works because there are too many people depending on it, and even if we could, this is not the place :P
I think we went a little off-topic here, so let's get back to the discussion. > 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. > 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. > That may be a bigger change, but there's enough angst around this issue that > we would be better off getting it right this time, even if it changes things, > than continuing to preserve the system that people dislike so much. This may be completely wrong for other people, but is my understanding. AFAIK those these issues come from lack of separation between the distro, system and user environments, causing a hell of conflicts and silent module shadowing that neither the system package manager or pip can fix. Almost every time I help people with Python I have to tell them to use a virtual env, which most people aren't expecting, and would likely run into issues had I not suggested it. Considering that, I think this approach, including the CLI option, would be a step forward. How big would that step be, I am not sure, but probably not *that* big. But yeah, this is, of course, my experience, and that can vary for other people, so there may be different perspectives here. So I'd very much like to hear other people on this. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43976> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
