argparsing: support parser.addini(type="paths") which returns pathlib.Paths #8594
Conversation
| @@ -1427,6 +1427,12 @@ def _getini(self, name: str): | |||
| dp = self.inipath.parent | |||
| input_values = shlex.split(value) if isinstance(value, str) else value | |||
| return [legacy_path(str(dp / x)) for x in input_values] | |||
| elif type == "paths": | |||
| # TODO: This assert is probably not valid in all cases. | |||
There was a problem hiding this comment.
Note: this is copy/paste from branch above
As far as I can see, pytest itself does not have For plugins, I think they can just change from |
|
Perhaps im overly pedantic over Integration, this might break plugins that reach into the options of other plugins |
I don't think there is much we can do about that |
|
|
||
| The value of ini-variables can be retrieved via a call to | ||
| :py:func:`config.getini(name) <_pytest.config.Config.getini>`. | ||
| """ | ||
| assert type in (None, "string", "pathlist", "args", "linelist", "bool") | ||
| assert type in (None, "string", "paths", "pathlist", "args", "linelist", "bool") |
There was a problem hiding this comment.
lets put in a DeprecationWarning while at it
There was a problem hiding this comment.
I think we should handle all of the py.path deprecations as one, otherwise we will need at least a dozen different warning types which would be a mess for the users.
There was a problem hiding this comment.
we need different warnings for different cases, so im thinking its a little better to add them while we integrate that
plus it gives everyone the opportunity to start their own porting/support for the new apis as soon as they are available (instead of later) (all the things going to warn at once seems daunting to me personally)
There was a problem hiding this comment.
we need different warnings for different cases, so im thinking its a little better to add them while we integrate that
I was thinking we collect them all together in one place https://docs.pytest.org/en/stable/deprecations.html.
plus it gives everyone the opportunity to start their own porting/support for the new apis as soon as they are available (instead of later) (all the things going to warn at once seems daunting to me personally)
Interesting, to me it's the exact opposite - I'd rather be able to do all the work at once, at a definite version point (especially as a plugin), then to do it in drips across multiple versions.
There was a problem hiding this comment.
@bluetech makes me think i want to start a extra addon to enable determining when a warning should start to appear (so we can coordinate warning start and feature end more detailed, but thats for later, we can decide on the exact mechanism later
but yeah, the perspectives are indeed different, i prefer steady small changes over all at once changes,
but i also see the drag that can be triggered by having changes belonging to a larger scheme tickle in
im happy to leave the particular warnings out and defer the warning topic for later
There was a problem hiding this comment.
OK, thanks.
I'll try to work on the coordinated py.path deprecation today or tomorrow. We still have the reportinfo headache, but I'm think just deferring that specific one is OK.
There was a problem hiding this comment.
I missed this review completely, but wanted to comment on this:
Interesting, to me it's the exact opposite - I'd rather be able to do all the work at once, at a definite version point (especially as a plugin), then to do it in drips across multiple versions.
Same for me, it would be much more annoying to have to deal with warnings for the same issues across multiple versions than just sitting down and fixing it once.
Part of issue #7259, specifically #7259 (comment).