Log file Viewer

[13:50:39] <agronholm> can anyone tell me how this can work? https://bitbucket.org/openpyxl/openpyxl/src/f7d02b93ed86d345876a3bd2488207b16d774d2b/setup.py?at=default&fileviewer=file-view-default#setup.py-69

[13:50:48] <agronholm> there's no such documented option in setuptools

[13:50:59] <agronholm> yet this is displayed on the project's pypi page

[13:51:58] <Wooble> agronholm: it's from distutils.

[13:52:14] <agronholm> is it supposed to work like this?

[13:54:05] <agronholm> apparently not

[13:54:13] <agronholm> no effect...

[13:54:16] <mgedmin> I think it's simply ignored, yes

[13:54:25] <agronholm> ah well

[13:54:42] <agronholm> I do recall from the days of distutils2 that there was indeed something along these lines

[13:54:48] <Wooble> Well, it's not ignored. It's displayed on pypi. :)

[13:55:15] <Wooble> oddly, it's not documented in the docs for distutils.core.setup, but referred to elsewhere in the distutils docs.

[13:55:34] <agronholm> I would just like to get rid of those silly "if sys.version_info < ..." blocks

[13:55:55] <dstufft> requires is not a thing you want to use

[13:55:56] <Wooble> agronholm: oh, it definitely doesn't do anything when you're installing.

[13:56:11] <agronholm> dstufft: yeah, figured

[13:56:36] <dstufft> The intent of requires was for people to list the things their project requires to import

[13:56:48] <dstufft> like, if you do ``import django``, you'd require ``django``

[13:57:04] <dstufft> so it's sort of like install_requires... but for ``import`` names

[13:57:10] <dstufft> which is not really useful

[13:57:21] <dstufft> and nothing does anything but display it (I think in warehouse we don't even display it)

[13:57:28] <agronholm> not a lot of thought went to packaging and distribution early on

[13:58:25] <agronholm> wheels have improved things somewhat

[13:58:33] <dstufft> well, a lot of the early packaging work makes more sense if you view it in the context that there was no automated tooling, so everything was there primarily for informational purposes for users to manually use

[13:58:44] <dstufft> and that distutils was designed to be a cross platform alternative to Makefiles

[13:59:10] <Wooble> I think not displaying it is too bad; IMO it's more elegant than using classifiers for every version that will work. Shame it never actually did anything else useful though.

[13:59:33] <Wooble> (of course, I didn't even know it displayed in pypi until now so it's not like I'll miss it)

[13:59:47] <dstufft> I mean, that's a bit of a hack

[13:59:52] <dstufft> because you don't ``import python``

[14:00:08] <agronholm> iirc there was such support in the metadata defs

[14:00:10] <dstufft> it's just using the fact that nothing does anything with it, so it's effectively just a string to shove some data

[14:00:17] <agronholm> at least at some point

[14:00:18] <Wooble> and ironically the classifiers are much harder to read on warehouse :(

[14:00:20] <dstufft> there is yes, a requires_python field

[14:00:27] <agronholm> but you can't use it :)

[14:00:36] <dstufft> Wooble: Oh, Warehouse hasn't been really designed yet

[14:00:51] <dstufft> just me half assing shit around

[14:01:24] <dstufft> The designer is planning to get it ready for real between now and mid decemberish

[14:01:51] <agronholm> Wooble: I've resorted to manually specifying the wheel tags and adding that sys.version_info check in setup.py

[14:02:47] <dstufft> agronholm: well, if you put some effort into it (you'll have to trick setuptools to sending that info) you can get requires_python to be displayed on PyPI, but nothing wills upport it again so it'll just be ignored (for now anyways, eventually no)

[14:03:02] <agronholm> dstufft: yeah, that's why I don't try

[14:04:13] <Wooble> agronholm: I'm happy to let the only marginally useful thing I have on pypi install fine and blow up on import if someone's using python 2.5 and didn't RTFM.:)

[14:05:00] <agronholm> Wooble: sadly people who don't RTFM and have it blow up on them sometimes file bug reports

[14:05:05] <dstufft> obviously you should just toss some incompatible syntax in __init__.py

[14:05:18] <agronholm> dstufft: a surefire way to get bug reports

[14:05:46] <Wooble> agronholm: yeah, it helps that my module targets librarians, who actually know how to read :)

[14:06:05] <agronholm> I've had python 3.2+ users complain to me that the 2.x backport of concurrent.futures does not work for them

[18:01:23] <nanonyme> Should it?