Log file Viewer
#pypa logs for Wednesday the 2nd of December, 2020
[11:04:07] <mcepl> jaraco: https://github.com/python/importlib_resources …. are you sure that this is necessary for 3.7 and 3.8,? According to https://docs.python.org/3/library/importlib.html#module-importlib.resources it is included since 3.7
[14:32:06] <pviktori> Dear pip developers: in 2017, https://github.com/pypa/pip/issues/4288 (warn on `sudo pip install`) was closed as duplicate of #1668 (default to `--user`), which was then solved somewhat differently than envisioned in 2017. Could you reopen #4288 for a bit more discussion? Or is there a better place?
[14:32:44] <pviktori> My concern is that `sudo pip install` still appears in variuos tutorials, and still usually a bad idea. Even if pip devs disagree, it would be nice to have that opinion as a linkable comment.
[14:38:55] <dstufft> pviktori: I thiink the big thing is `sudo pip install`` is not actually the problem, it's just a convienant shorthand for the problem scenario-- but because it's a short hand it doesn't actually translate 1:1 to cases where the problem exists
[14:39:35] <dstufft> IOW, the real problem isn't `sudo pip install`, it's "pip and this other package manager are trying to both compete over ownship over this particular python install"
[14:40:39] <pviktori> dstufft: so, separate directories for system-installed and pip-installed pkgs sounds like a good idea. Right?
[14:41:07] <dstufft> pviktori: maybe, you still have the problem that it gets flattened at runtime into a single shared view of what's installed
[14:42:17] <dstufft> pviktori: FWIW I'm trying to look to see if we have an issue open for this already, because I think the right solution here is to provide some sort of mechanism to tell pip that some python is being managed by something else
[14:43:10] <pviktori> ah, we also default to making system-installed software run in Python's isolated mode
[14:43:58] <dstufft> but you can imagine like, a root owned virtualenv should probably not give a. warning not to use sudo pip install, or if someone uses pyenv to install a root owned separate copy of Python (docker? etc)
[14:44:09] <dstufft> I lose track of which distros which people are involved with, and which work arounds each one has applied to the problem
[14:45:06] <pviktori> Yes, the Docker case is why we originally suggested that `sudo pip` would warn rather than outright fail.
[14:49:58] <dstufft> I think the fundamental question here is, in a system managed python, should pip be able to do *anything* to that environment? Or should pip treat that as entirely hands off (without some sort of "I'm an expert and I know what I'm dong" flag). There's different designs we might come up with, depending on the answer to that question (if the answer is no, then we just need a sigil that tells pip to leave this python alone, if it's yes then we probably
[14:49:59] <dstufft> need a split path, and some way for distros to protect their stuff against pip installed stuff)
[14:51:03] <pviktori> dstufft: I don't think we two can decide that on IRC. Where is the best place to ask? A new issue? Discourse?
[14:52:07] <dstufft> ANyways, to answer your original question, I think, at least personally, a warning is probably not the way we'd want to go with it, mostly because I think we can do better than a warning that most people will jsut ignore anyways :) I think it would be worthwhile to either open an issue on pip's repository to discuss how we can make pip/distros paly better together, or probably a better thing. is to talk over on discourse and figure out a non pip
[14:52:07] <dstufft> specific solution we want to go down, and then get whatever PEPs we need (if any, maybe we can do it just in issues, and then open up issues to implement our decisions)
[14:52:54] <dstufft> I think between the various popular distros, we have like 2 or 3 solutions that sort of 60% solve the problem
[14:54:17] <ozzzo> I'm trying to use pip inside a docker container, and it seems to be interpreting the file path as a hostname. How can I fix this?
[14:54:37] <ozzzo> Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after connection broken by 'NewConnectionError('<pip._vendor.requests.packages.urllib3.connection.HTTPConnection object at 0x7f48cea6e190>: Failed to establish a new connection: [Errno 101] Network is unreachable',)': /pypi/simple/adjutant-ui/
[14:56:22] <pviktori> dstufft: So, I went to create a new Discourse topic, and the forum suggested https://discuss.python.org/t/playing-nice-with-external-package-managers/1968/23
[14:57:44] <pviktori> dstufft: could you please add a comment to https://github.com/pypa/pip/issues/4288 saying something like "#1668 ultimately solved a different problem. More discussion about this issue is at <discourse>." ?
[14:57:58] <dstufft> pviktori: I like that we both (I think) participated in that, and neither one of us remembered it :D
[15:05:35] <dstufft> pviktori: re-reading this has jogged my memory, I think the "right" solution is teach distro tooling to emit MANAGED-BY, and teach python tooling that MANAGED-BY means "don't touch", then get a Debian style split where distros install to /usr and pip installs to /usr/local (and then each distro can decide if they want to exclude /usr/local from sys.path when running system provided tools or not
[16:40:10] <FFY00> mcepl, importlib.resources although included in the standard library since 3.7, has received new features (ctrl+f "New in version"), the backport brings those new features back to older Python version, including 3.7 and 3.8, for users that need them
[23:19:32] <jaraco> mcepl: it depends on what features you need. Python 3.9 added the `files` as a new API to supersede the old API, so users that wish to have that functionality and support Python 3.8 should use importlib_resources.