Log file Viewer

[08:42:00] <micisuta> Does anyone have any pointers on how to use the the tags defined in PEP0427 within the setup.py? I'm trying to understand how these and the platforms entry to setuptools.setup interact

[15:15:45] <sumanah> hi micisuta

[15:16:09] <sumanah> looking at https://www.python.org/dev/peps/pep-0427/ now

[15:16:09] <micisuta> hi

[15:16:15] <sumanah> (saw your question via http://kafka.dcpython.org/day/pypa-dev/2019-06-21 )

[15:18:10] <sumanah> checking https://packaging.python.org/guides/packaging-binary-extensions/?highlight=setup.py in case it helps

[15:18:41] <sumanah> not sure, but https://mail.python.org/mailman/listinfo/wheel-builders might be able to help you micisuta

[15:19:03] <micisuta> I did get an answer by looking at the pip sources and find out what get_supported() returned across a variety of architectures and versions.

[15:19:07] <micisuta> Ok, I'll take a look

[15:19:53] <sumanah> micisuta: oh cool, what was your answer? maybe you could note it in a https://github.com/pypa/packaging-problems/issues/ issue and it could get added to docs?

[15:21:10] <micisuta> I will do that, but for completeness here: I imported pep425tags from pip._internal and the called pep425tags.get_supported() on those different Python versions

[15:21:32] <micisuta> I then saw lists like: [('cp27', 'cp27mu', 'manylinux1_x86_64'), ('cp27', 'cp27mu', 'linux_x86_64'), ('cp27', 'none', 'manylinux1_x86_64'), ('cp27', 'none', 'linux_x86_64'), ('py2', 'none', 'manylinux1_x86_64'), ('py2', 'none', 'linux_x86_64'), ('cp27', 'none', 'any'), ('cp2', 'none', 'any'), ('py27', 'none', 'any'), ('py2', 'none', 'any'), ('py26', 'none', 'any'), ('py25', 'none', 'any'), ('py24', 'none', 'any'), ('py23', 'none', 'any'), ('py22', 'none',

[15:21:33] <micisuta> 'none', 'any'), ('py20', 'none', 'any')]

[15:23:32] <sumanah> Thanks micisuta!

[16:16:31] <sumanah> pradyunsg: I just saw https://discuss.python.org/t/packaging-and-python-2/662/129 in my email. You are such a rebel that Discourse has to SILENCE YOU?

[16:16:51] <pradyunsg> sumanah: Yep. :)

[16:17:06] <sumanah> you dangerous heretic

[16:19:10] <pradyunsg> Uh, sumanah ^

[16:19:19] <sumanah> oh goodness

[16:19:30] <sumanah> maybe it depends on how many badges I accumulate?

[16:19:35] <pradyunsg> Nope.

[16:20:29] <sumanah> I ..... ok

[16:20:41] <sumanah> will figure things out

[16:20:57] <pradyunsg> Lemme poke on it to break your streak. :)

[16:21:39] <pradyunsg> ^if you want.

[16:22:24] <sumanah> pradyunsg: btw do you have a WebAuthn key? if you don't you could post and ask whether there is anyone giving 'em out for free

[16:22:49] <sumanah> because I think there are some companies doing that as free gifts for open source maintainers

[16:23:02] <pradyunsg> Nice idea. :P

[16:25:26] <pradyunsg> sumanah: posted. :)

[16:26:02] <sumanah> :) thanks pradyunsg

[16:26:27] <sumanah> pradyunsg: remind me, when is your next international travel?

[16:27:06] <sumanah> and relatedly, is there a method for people to reliably ship things to you (reliably meaning that you have, like, an 85%+ chance of receiving it)?

[16:27:17] <pradyunsg> sumanah: Aug, to Korea.

[16:28:35] <pradyunsg> sumanah: My Mumbai address will be assured -- if it reaches there, it reaches me.

[16:28:45] <sumanah> Great

[16:29:04] <pradyunsg> Otherwise, my college address if it'll reach me within 4-5 months, starting July. :)

[16:29:26] <sumanah> Right :)

[16:29:45] <pradyunsg> sumanah: ^ + mumbai will reach me "eventually" after July. Does that make sense?

[16:29:56] <pradyunsg> *july begins

[16:29:57] <sumanah> btw, folks interested in our 2FA work, woodruffw wrote up https://blog.trailofbits.com/2019/06/20/getting-2fa-right-in-2019/ which has a bunch of interesting context on the different tradeoffs that WebAuthn and TOTP make

[16:30:46] <sumanah> pradyunsg: if I need to actually send you something I'll ask you to clarify re: dates, and give me addresses :)

[16:31:23] <pradyunsg> sumanah: Yep. XD

[16:31:28] <sumanah> pradyunsg: anyway I shall stop distracting you from your refactoring work

[16:33:00] <pradyunsg> sumanah: hehe, no worries. I've budgetted 1 hour right now, for trying to see if I can make images out of this PyPI download data that I just queried.

[16:33:22] <sumanah> pradyunsg: images like data visualizations?

[16:34:02] <pradyunsg> sumanah: yep!

[16:34:09] <sumanah> best wishes!

[16:34:19] <pradyunsg> thanks! :D

[18:30:58] <sumanah> [currently listening to https://music.metafilter.com/8555/How-Far-Ill-Go a rock cover of a song from the Disney movie "Moana"]

[20:13:16] <sumanah> pradyunsg: you awake and can answer a question or 2 for me?

[21:03:27] <sumanah> dstufft: Pradyun mentioned to me that you've started PEP 592 (yanking) support in pip as well as Warehouse? is that right and is it anywhere I can link to?

[22:57:44] <sumanah> hey techalchemy - thanks for the update in https://github.com/pypa/packaging-problems/issues/215#issuecomment-504596934

[22:58:13] <techalchemy> sure thing, thanks for posting there and moving it along

[22:58:45] <techalchemy> beats rerunning my failed tests over and over again

[22:59:30] <sumanah> :)

[23:00:21] <sumanah> techalchemy: what are your plans for the afternoon/evening? Want to help me with something?

[23:08:17] <techalchemy> sumanah: depends, i may have to help my gf pack but she isn't home yet so i am free for now

[23:08:31] <techalchemy> how can i help?

[23:09:21] <sumanah> techalchemy: got it! Can you check https://wiki.python.org/psf/Fundable%20Packaging%20Improvements and tell me whether anything on there is just flat-out inaccurate or misleading?

[23:10:41] <techalchemy> oh there is a lot more info than last time i looked

[23:11:56] <sumanah> yeah -- https://github.com/pypa/pip/issues/6536 has some context

[23:12:05] <sumanah> for why I did this

[23:15:35] <sumanah> I felt like there was no 1 quick easy-to-read explanation for: "here's why the pip resolver is an important project, here's all the stuff that is blocking on it, here's what funding would help with" -- the current GitHub issue (988) is now very long, and Sebastian Awwad's explanation doesn't list out all the features & bugs that are blocked on a new resolver

[23:17:08] <sumanah> techalchemy: and I know you were curious about why I thought the new resolver was a high priority so I figure you're a good sample audience for this, plus, I welcome factchecking

[23:22:02] <techalchemy> sumanah: yeah this is awesome

[23:22:05] <sumanah> :D

[23:22:09] <techalchemy> sorry I got distracted commenting

[23:22:14] <sumanah> oh no prob

[23:22:24] <techalchemy> because i can see where to go to comment on resolver related issues

[23:23:01] <techalchemy> yeah there is a serious challenge around like, topic-based organization of github issues and discussions in general

[23:23:06] <techalchemy> it's so hard to track anything down

[23:23:18] <sumanah> techalchemy: I think this is a good case for a "project"

[23:23:35] <sumanah> like https://github.com/pypa/pip/projects/3

[23:23:36] <techalchemy> yeah but like, I'm not a pip maintainer

[23:23:41] <techalchemy> so I never look at pip projects

[23:23:53] <sumanah> ah I think I understand

[23:24:34] <techalchemy> but many of these things are tangentially relevant at the very least, yet the overhead of keeping up would be super high

[23:24:37] <techalchemy> doubt there is a solution

[23:25:01] <sumanah> techalchemy: so I have sort of a stab at an idea.....

[23:25:26] <techalchemy> sumanah: I sort of doubt the resolver will fix conda compatibility btw but it will get us talking more

[23:25:29] <sumanah> techalchemy: for any given FLOSS project there are actually very few of these kinds of knotty Mega Architecture Problems/Projects That Affect A Zillion Other Things

[23:25:47] <techalchemy> really?

[23:25:54] <techalchemy> man i picked the wrong project to be involved in

[23:26:02] <sumanah> techalchemy: heh

[23:26:10] <sumanah> techalchemy: when I say "very few" let's say, under 10

[23:26:33] <techalchemy> i mean pipenv is just a resolver so it makes sense that this is mostly my life

[23:26:35] <sumanah> usually, in my experience

[23:26:37] <sumanah> ahhhh

[23:27:20] <techalchemy> so is passa (which me and tzu ping / pipenv comaintainer wrote because we got sick of working on pipenv)

[23:27:58] <techalchemy> and yeah I mean if you want to know the kinds of issues having a resolver in pip solves, it's basically uh

[23:28:18] <techalchemy> https://github.com/pypa/pipenv/issues?q=is%3Aopen+is%3Aissue+label%3A%22Category%3A+Dependency+Resolution%22

[23:29:07] <sumanah> oh cool I should look through that, thanks techalchemy

[23:29:37] <techalchemy> i mean it's not exhaustive and many are pipenv specific @ sumanah but the thrust is just that there are a lot of 'x + y = broken'

[23:29:45] <sumanah> right

[23:30:25] <techalchemy> and dependency resolvers themselves are super complicated because yeah we wrote in support for pep517 but pip needs to support this functionality going backward to things that do all types of crazy shit in their setup.py

[23:30:51] <sumanah> techalchemy: so -- to get back to topic-based organization of issues & discussions -- this is something that we actually did reasonably well when I was working on MediaWiki, in my opinion, because someone would start a wiki page for any given Knotty Project and that would be like the table of contents

[23:31:07] <techalchemy> oooh yeah

[23:31:53] <sumanah> and we were pretty good about gardening those wiki pages because, well, we were all wiki editors too

[23:32:45] <techalchemy> that works better than 'file issues all over and hope someone finds them'

[23:33:14] <techalchemy> if we standardized issue labels across the pypa we could have some script that runs and aggregates them

[23:33:29] <techalchemy> hm, maybe thats a bad idea