-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define block setup_requires_interior #149
Define block setup_requires_interior #149
Conversation
Oooof ... good catch. I don't really remember why I put it in setup.cfg. |
@dHannasch I'm thinking now about moving that tests_require in setup.py as well - but with a briefer comment - what do you think? |
Hrm. It looks like they generally recommend using setup.cfg when possible, or rather, they want to recommend that but are worried about older versions before setup.cfg was supported. pypa/packaging.python.org#378 (Of course setup_requires can't be in setup.cfg because setup.cfg isn't sophisticated enough to handle things like "require CFFI but only sometimes." But tests_require can be in setup.cfg.) To be honest I'm not sure why they recommend that, but if I had to guess it's because setup.cfg is easier to read, because there's usually some "mess" in setup.py to handle all kinds of oddball problems. |
Seems they are still talking about it (pypa/sampleproject#57 and the mostly empty https://github.com/pypa/sampleproject/blob/master/setup.cfg). The I wouldn't trust them on anything regarding best practices tho, packaging.python.org is more of a cookbook that tries to give some overview on packaging. Give then fact that duplicated metadata in setup.py and setup.cfg ain't merged I'm thinking it's a bad practice to spread it across the two files, and it's impossible to have everything in setup.cfg. Therefore it's logical to conclude that the best practice is ... the opposite of pypa/packaging.python.org#378 :) |
I'll merge this for now to avoid brokenness and we deal with the tests_require later maybe. |
To clarify, you're talking about deleting setup.cfg entirely, right? Or maybe not. I can see the logic of, when multiple places might hold settings, keeping the settings only in the highest-priority place. That applies to pretty much everything in setup.cfg, because setup.cfg is never the highest-priority place. E.g. pytest.ini overrides setup.cfg, and the settings are not merged. http://doc.pytest.org/en/latest/customize.html I guess I had been wondering whether we might want separate files .flake8, pytest.ini, etc. |
Incidentally, is your computer clock two days slow? |
Oooof ... ntp service was hosed :\ |
Well I put what I could in setup.cfg to avoid dozens of root-level files. Coveragerc wasn't moved there because pytest-cov doesn't work nice with non-default file (it's messy and can't be fixed). I was suggesting moving out just the tests_require. Maybe we could move out all to separate files - don't know what to say - it's a try it and see how it looks thing. |
…that includes both pytest-runner and setuptools_scm as appropriate.
Resolves #147.
Note that this still has two Travis failures on ENV=pure-private (due to #146) and ENV=matrix-cext (that will be fixed by #145).