pytest-dev
refactor config file finding
addresses #3523
setup.cfg
also a structural refactor and cleanup of the config file finding/loading
- [ ] changelog
- [x] writeup in deprecated docs/links
The discussion in #3523 is interesting, seems this will bring a lot of pain to our users that still keep their configuration in setup.cfg, because those that have working suites today are not being affected by the issues in #3523, so I wonder if there's other path than dropping setup.cfg support completely?
What would be the downsides of keeping the existing support, even if for some options it doesn't work so well (filterwarnings seems to be an example of that)?
@nicoddemus in that case lets turn setup.cfg support into something undocumented, and keep support based on the basic testing
in future we might want to try using config-parser to load setup.cfg data
based on recent developments of config-parser it may even be possible o drop inconfig and use different config-parser configurations for different config-file setups as part of a breaking release
@nicoddemus in that case lets turn setup.cfg support into something undocumented, and keep support based on the basic testing
I would be fine with that. 👍
We can remove examples of setup.cfg usage, and just leave a note stating that while it "works", there are situations where it doesn't and is not really recommended. This way if any bug reports come along because of setup.cfg support, we can just point that to users and suggest they change the configuration format.
in future we might want to try using config-parser to load setup.cfg data
based on recent developments of config-parser it may even be possible o drop inconfig and use different config-parser configurations for different config-file setups as part of a breaking release
I'm not keen on the details, but the overall idea seems good. 😁
reviewed the docs and decided the warnings @nicoddemus did put in way earlier are good enough