Log file Viewer

[01:29:19] <MurderManTX> hello

[01:55:46] <Jellyg00se> Hi, I'm trying to install pip3 install --user deluge-libtorrent (pip 9.0.3 python3.6), but I always get a cannot satisfy the requirement error. The package is in pip search and on pypi, and I'm wondering what makes this happen? Many thanks

[02:04:42] <tos9> Jellyg00se: Can you pastebin your full command and error

[02:06:35] <Jellyg00se> https://pastebin.com/3SauwZ5q

[02:06:48] <Jellyg00se> I always seem to have trouble with python and pip versions probably something missing :P

[02:08:55] <tos9> Jellyg00se: Can you run that again as `python3 -m pip install --user -vvv deluge-libtorrent`, and then also show me `python3 --version`, and tell me what OS you're on

[02:09:08] <tos9> Long story short, the answer is going to be that that package isn't uploaded properly

[02:09:12] <Jellyg00se> no problem, it's centos 8 but I'll pastebin it for you

[02:09:35] <tos9> Yeah. It just uploads 1 wheel, and just for Windows

[02:10:09] <tos9> Probably pip should show a better error message for this case, it comes up really often.

[02:11:50] <Jellyg00se> aah I see, pretty sure that's the correct dependency from the official deluge page but it's a little unclear get the same for libtorrent too

[02:12:39] <tos9> (OK, what I just mentioned is already this issue: https://github.com/pypa/pip/issues/6526 )

[02:13:04] <tos9> Jellyg00se: I mean, if you need/want that package you'll likely now have to go back to its docs and see how it supports being installed

[02:13:53] <tos9> This is a packaging antipattern, so you also might want to go back to its issue tracker and file a bug saying "please upload sdists" and / or "please upload wheels for more platforms", but it's unfortunately a common antipattern (e.g. even prominent packages like tensorflow make this mistake), so you might find some pushback

[02:14:42] <Jellyg00se> just trying to understand it a bit better, so do you mean that they haven't uploaded the dependencies for the correct distribution versions and then it's moaning as it can't be found?

[02:15:58] <Jellyg00se> I imagine eventually the software will be added to the main repos or epel, but centos 8 is a new release so I was trying to get it built from python deps :)

[02:16:03] <Jellyg00se> Thanks for your help tos9

[02:16:12] <tos9> Jellyg00se: No, basically what that means is -- there's a file uploaded, but that file only works on windows

[02:16:26] <Jellyg00se> ye

[02:16:38] <tos9> Jellyg00se: That file was built from another file (roughly speaking), and that first source file works "everywhere", but they didn't upload that first source file

[02:16:50] <tos9> I'm being imprecise, and a bit facetious, but roughly, that's the explanation for you as an end user

[02:16:54] <Jellyg00se> oh right

[02:17:07] <Jellyg00se> haha, yeah cheers, I get the idea

[02:17:27] <tos9> Jellyg00se: If you're familiar with like I don't know C or something, it's as if someone uploaded the built binary, but not the source files, so you can't cross compile for some other architecture

[02:17:31] <Jellyg00se> surprised that it's even visable within pip search if the file for the platform doesn't "exist" or whatnot

[02:17:42] <Jellyg00se> I see

[02:17:47] <tos9> Jellyg00se: pip search doesn't care about whether there are files uploaded at all

[02:17:53] <tos9> it'll show any package that is registered

[02:17:55] <Jellyg00se> I guessed that after you explained it haha

[02:18:04] <Jellyg00se> good to know

[03:59:38] <energizer> after running sudo pip and broken it, What is the canonical answer to fixing `ImportError: cannot import name 'main'`?

[07:06:16] <dbrgn> pombreda__: thanks for the update regarding the blake hash. still returns "NoSuchKey unfortunately (2b31aa67f2477a7da992c759ca7f7a62420af9a967aee438f816eaaf64f2748b -> curl https://files.pythonhosted.org/packages/2b/31/aa67f2477a7da992c759ca7f7a62420af9a967aee438f816eaaf64f2748b/fahrplan-1.1.1.tar.gz.asc).

[07:06:50] <dbrgn> is it possible that the sigs can only be uploaded together with the release?

[07:09:53] <dbrgn> pombreda__: I bumped the release version to 1.1.2 and created a new release. worked flawlessly from the start. it really does seem that signatures aren't accepted anymore later (or that it's a twine issue).

[08:10:19] <pombreda__> dbrgn: it makes some sense to have the package and its signature uploaded together I think (you could dive in the warehouse code to track if there is such a thing checked)

[08:10:57] <pombreda__> glad things worked out for you!

[08:31:57] <dbrgn> pombreda__: yeah of course, but in this case I simply forgot to generate the sigs when I did the release :)

[12:41:25] <pombreda__> dbrgn: is there any tools except for debian that uses these signatures?

[13:46:02] <dbrgn> pombreda__: I use them for Arch Linux AUR packages.

[13:47:15] <dbrgn> basically any installer that wants to verify the integrity and authenticity of a package using something other than TOFU (trust-on-first-use using the hashes) would use those signatures.

[13:47:43] <dbrgn> because you only need to trust the key of the packager once, and can then verify every subsequent release.

[14:14:07] <pombreda__> dbrgn: +1

[14:37:08] <dbrgn> pombreda__: in arch linux it's actually quite convenient, you just add an .asc file to the sources and specify "validpgpkeys" :) https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fahrplan

[14:37:18] <dbrgn> verification is done automatically.