Log file Viewer

[00:27:16] <sigmavirus24> agronholm: I believe that's for wheel and it's there for correctness

[00:27:35] <agronholm> but wheel doesn't have any of that stuff

[00:28:45] <agronholm> setuptools does support that stuff in setup.cfg but it has to be in [options] and install_requires=

[00:29:11] <agronholm> sigmavirus24: see here for a practical example: https://github.com/asphalt-framework/asphalt/blob/master/setup.cfg#L23

[00:30:14] <agronholm> hm, wheel *does* say it supports something like that

[00:30:31] <agronholm> but that won't work with "pip install -e ." then

[00:30:40] <agronholm> so you end up writing the requirements twice then

[00:33:23] <sigmavirus24> agronholm: my concern is not `pip install -e .`

[00:33:39] <agronholm> what is it then?

[00:33:40] <sigmavirus24> my concern is the result of `python setup.py bdist_wheel`

[00:34:13] <sigmavirus24> that metadata requires-dist translates to the requirements (especially extras and python version specific) when a user pip installs a wheel from PyPI

[00:34:15] <agronholm> well, if you specify the requirements like in the example I linked, it will work with both wheel and a develop install

[00:34:43] <agronholm> no need for duplication

[00:34:50] <sigmavirus24> I don't remember that being a thing when we started using requires-dist

[00:35:00] <agronholm> setuptools didn't support it back then

[00:35:01] <sigmavirus24> I'm happy to merge something like that if it works

[00:35:12] <sigmavirus24> I'm sure urllib3 would be happy to accept a PR like that too

[00:35:29] <agronholm> alright, just wanted to make sure we're on the same page :)

[00:35:44] <sigmavirus24> :+1: thanks for confirming

[00:39:19] <agronholm> sigmavirus24: do you happen to know why twine has all the metadata in its __init__.py? this is somewhat unusual

[00:39:23] <agronholm> and pointless I might add

[00:40:09] <agronholm> dstufft: as the author you might know better :)

[00:40:40] <dstufft> agronholm: *shrug*, a habit I developed at some point

[00:40:58] <agronholm> do you mind if I move the metadata to setup.cfg?

[00:41:08] <agronholm> (now that it's possible)

[00:41:41] <dstufft> You'd be better off asking sigmavirus24 than me, he has been maintaing it now, and idc what he decides either way :)

[00:41:59] <agronholm> sigmavirus24: ^

[00:42:15] <agronholm> I'm putting together a PR now

[00:49:22] <agronholm> sigmavirus24: you're also not listed as the maintainer, maybe we should fix that too?

[00:53:26] <sigmavirus24> I don't care

[00:53:30] <sigmavirus24> (About being listed as maintainer)

[00:54:05] <sigmavirus24> The metadata in __init__.py means people not having to use slow things like the pkginfo library

[00:54:11] <sigmavirus24> They can get the metadata as necessary

[00:54:27] <sigmavirus24> It's far more accessible for programs and people like buildout that insist on importing parts of twine

[00:56:22] <agronholm> if you ARE the maintainer, then not providing that info is a disservice to the users

[00:56:42] <agronholm> are python 3.2 and 3.3 still supported by twine?

[00:59:24] <sigmavirus24> 3.2 and 3.3 aren't even tested so probably no

[00:59:31] <sigmavirus24> and many libraries we rely on don't work on 3.2

[00:59:54] <agronholm> I will remove them from the classifiers then and add a python_requires to that end

[00:59:54] <sigmavirus24> PyPA is really the group maintaining twine. I just try to prioritize replying more than others

[01:02:45] <sigmavirus24> agronholm: fwiw, these changes will be more reviewable if they're broken up over a few PRs, at least, that's how I prefer to review things

[01:03:01] <agronholm> that will be a lot more work

[01:04:06] <agronholm> ugh: python_requires = >=2.7,!=3.0,!=3.1,!=3.2,!=3.3

[01:04:21] <agronholm> why is there no "or" operator

[01:06:32] <sigmavirus24> agronholm: I'm sorry that it seems like a lot more work. In my experience "Fix all the things" PRs end up breaking things regardless of how innocent they seem initially because something always gets missed

[01:09:16] <agronholm> sigmavirus24: are you completely against moving the metadata to setup.cfg?

[01:09:38] <agronholm> if so, I don't see any point in any of this

[01:09:49] <agronholm> (and I've wasted my time)

[01:12:00] <agronholm> does twine have a Python API?

[01:13:52] <agronholm> doesn't seem that way

[01:14:03] <agronholm> so I'm not sure who those things in __init__.py are for

[01:14:12] <agronholm> if the docs have no indications that they're there

[01:51:15] <sigmavirus24> agronholm: there is a budding API but the documentation was never written

[01:51:18] <sigmavirus24> That will be expanded

[01:52:13] <sigmavirus24> I'm not against moving metadata to setup.cfg but I'm also not in favor of random massive shifts in relatively low priority things all thrown into one large PR

[01:52:17] <agronholm> this is what I had for the setup.cfg

[01:52:21] <agronholm> https://paste.ofcode.org/nTVxChnEaSE45yEEv7XzqK

[01:53:09] <agronholm> I can do it a little bit more gradually but I'm not sure what things I'm allowed to do in one PR and what not to

[01:54:10] <sigmavirus24> If you're adding all of that to setup.cfg that looks good in one Pr

[01:54:21] <sigmavirus24> Changing the metadata in __init__.py seems ill-advised

[01:54:58] <agronholm> the with-blake2 extra didn't seem to work at all to begin with

[01:55:01] <agronholm> had to rename that

[01:55:20] <agronholm> the only other change I made was removing the 3.2 and 3.3 classifiers

[01:55:34] <agronholm> oh, and replacing the explicit package names with "find:"

[01:55:43] <agronholm> I can undo those changes if you want

[01:57:16] <agronholm> IMHO the extra should be named "blake2"

[01:57:23] <sigmavirus24> If with-blake2 wasn't working that's depressing that no one reported that. Was it working before moving it to setup.cfg or is this a casualty of that? I'm +1 on removing the 3.2 and 3.3 classifiers. I think we can switch to `find:` but I want to make sure it isn't pulling in our tests

[01:57:57] <agronholm> I will try

[01:58:25] <agronholm> find: is not pulling the tests

[01:58:29] <agronholm> I checked

[01:59:30] <agronholm> hm, curious

[01:59:40] <agronholm> seems like it was a casualty of the setup.cfg conversion

[01:59:55] <agronholm> which leads to another question: why doesn't it work that way

[02:10:01] <sigmavirus24> I don't want "tests" listed as a package

[02:10:07] <sigmavirus24> Included in a .tar.gz? Sure

[02:10:19] <agronholm> told you, it's not included in the wheel

[02:10:43] <agronholm> but "find:" only includes the actual twine and twine.commands packages in packages=

[02:13:59] <sigmavirus24> :+1:

[02:14:03] <sigmavirus24> Sorry, we were agreeing

[02:21:14] <sigmavirus24> I'll probably get around to looking at your PR next week agronholm, Cheers!

[02:21:23] <agronholm> ok

[02:21:40] <agronholm> meanwhile I will try to find out why setuptools mangles the extra name

[02:21:56] <agronholm> it's fine like this in setup.py but if it's in setup.cfg it replaces - with _

[02:33:33] <agronholm> sigmavirus24: oh dear, the mangling code is in distutils

[02:34:03] <agronholm> so not much we can do about it :/