Log file Viewer

[11:19:39] <Alistair42> Hey, I'm looking for a bit of pip support. My company is using a custom made pypi and it's playing up with pip due to the 'Cache-Control: max-age=0' HTTP header that pip uses when fetching packages. Assuming I have no control over the pypi application, is there a client-side option or alternative to avoid using this HTTP header with pip?

[11:33:07] <lazka> Has anyone seen this before: `can't find '__main__' module in '/home/me/src/salsa/env/share/python-wheels/pep517-0.7.0-py2.py3-none-any.whl/pep517/_in_process.py'` ?

[11:33:50] <lazka> "pip install pygobject" has started to fail this way. started this week I think. If anyone can confirm maybe or has an idea.

[11:37:32] <lazka> here is the full trace: https://bpaste.net/raw/JKAA

[11:41:29] <lazka> ok, removing the pyproject.toml makes the build work again, so I guess a pip regression

[11:51:49] <lazka> I've filed a bug: https://github.com/pypa/pip/issues/7946

[11:57:17] <toad_polo> lazka: Is this on Debian?

[11:57:45] <toad_polo> I think that's due to Debian being Debian.

[11:58:07] <toad_polo> Install the latest pip from PyPI and it will fix your problem.

[12:09:38] <lazka> toad_polo, you might be right that this is Debian/Ubuntu specific as I can't reproduce on Arch. But I use the latest pip/setuptools on Debian/Ubuntu

[12:10:28] <lazka> I've added a minimal (two line) reproducer to the bug report btw

[12:10:58] <toad_polo> lazka: It needs to be reported to Debian.

[12:11:20] <toad_polo> They fuck with packages as part of their packaging.

[12:11:37] <andr_> lazka: did you use venv?

[12:11:44] <lazka> andr_, yes all venv

[12:11:57] <andr_> I can reproduce it in env created with venv but not one created with virtualenv

[12:12:00] <toad_polo> That's why installing the PyPI version fixes it, because they deliberately mangle their packages.

[12:12:08] <andr_> debian testing

[12:12:24] <lazka> (I first thought it's only my machine but I now got but reports for it)

[12:12:33] <lazka> andr_, thanks for testing

[12:13:53] <toad_polo> Using virtualenv will install the latest PyPI pip, which is why it fixes it.

[12:15:13] <lazka> toad_polo, you are right, I assumed "-U" would pull in the pypi version but Debian (for once) ships the latest, so I needed "--force-reinstall"

[12:16:01] <lazka> I'll report a Debian bug, thanks toad_polo, andr_!

[12:22:03] <toad_polo> lazka: Thanks for the report!

[17:34:03] <EWDurbin> test

[17:36:13] <EWDurbin> test

[17:36:24] <PSFSlack> <ewdurbin> test

[17:36:28] <EWDurbin> test

[17:36:30] <PSFSlack> <ewdurbin> test

[17:37:54] <tos9> succeeded

[17:40:15] <pradyunsg> Are we *also* bridging pypa-dev?

[18:22:06] <PSFSlack> <di> pradyunsg: yep

[18:25:44] <lazka> so the conclusion of my debian pip problems earlier today: debian installs all vendored pip dependencies as wheels into venvs and pep517 doesn't support being run from a wheel

[18:30:25] <pradyunsg> techalchemy: ^

[18:37:12] <toad_polo> lazka: Is there an issue report there?

[18:37:21] <toad_polo> I think we may have known that, but it's definitely a debian issue.

[18:40:18] <toad_polo> pradyunsg: This probably can be closed: https://github.com/pypa/pip/issues/7874

[18:40:28] <toad_polo> It's the debian issue, but there's nothing pip can do about it.

[18:40:47] <toad_polo> Looks like this is the upstream issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955414

[18:40:49] <lazka> toad_polo, yes, this is tracked in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955414 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954256

[18:40:55] <lazka> I just wanted to give a summary here

[18:42:23] <toad_polo> lazka: Thanks for reporting that upstream, and also for putting in the plug for "stop fucking with the packages" :P

[18:42:45] <toad_polo> It's infuriating that they do this for no reason.

[18:43:19] <toad_polo> I can't imagine a time when this has solved a problem, and it has clearly caused many problems - almost all of which fall on the upstream pip maintainers, who just think "pip is broken".

[18:43:45] <toad_polo> Er, rather, who get reports from users who just think "pip is broken" - understandably so.

[18:43:47] <lazka> ;) I'm a bit worried that it was to obvious

[18:44:41] <lazka> I have a package in Debian that vendors 2 Python libraries, luckily nobody has noticed yet :D

[18:45:21] <toad_polo> Those messages may have come out out of order. Matrix is being slow and weird, as usual.

[18:47:31] <lazka> and on the topic of debian ranting, it has started to split away distutils into its own package so it's no longer installed by default... and I get the bug reports about that..

[18:54:32] <toad_polo> I can imagine why. It doesn't seem to offer any benefits over Arch Linux.

[18:55:25] <toad_polo> People complain about Arch's instability, but Arch is so much more stable and reliable than Debian was for me, with the minor cost of just... keeping it up to date.

[19:15:22] <dstufft> eh

[19:15:23] <dstufft> the reason Debian wants to unvendor is they want to apply their patches to like, requests and stuff

[19:15:37] <dstufft> without having to maintain those same patches in every tool that vendors requests

[19:34:08] <techalchemy> there are plenty of reasons to unvendor things, including patching, but yeah

[19:34:37] <techalchemy> there is probably not very thorough understanding of the pep517 ecosystem etc

[19:36:11] <techalchemy> some of the changes are clearly a bit insane

[22:04:49] <toad_polo> I guess that makes sense.

[22:05:22] <toad_polo> Though the idea that they need to patch everything feels problematic.

[22:06:00] <toad_polo> At some point I imagine half the patches are to keep the other patches working.

[22:56:19] <techalchemy> toad_polo, it's not quite that bad

[22:56:47] <techalchemy> at least at canonical we do a lot of security patching

[22:57:12] <techalchemy> and a lot of supporting old versions for enterprise, so if the security fix has to be applied to an old version etc