-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
argparsing: support parser.addini(type="paths") which returns pathlib.Paths #8594
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,7 @@ | ||
Added :meth:`cache.mkdir() <pytest.Cache.mkdir>`, which is similar to the existing :meth:`cache.makedir() <pytest.Cache.makedir>`, | ||
but returns a :class:`pathlib.Path` instead of a legacy ``py.path.local``. | ||
|
||
Added a ``paths`` type to :meth:`parser.addini() <_pytest.config.argparsing.Parser.addini>`, | ||
as in ``parser.addini("mypaths", "my paths", type="paths")``, | ||
which is similar to the existing ``pathlist``, | ||
but returns a list of :class:`pathlib.Path` instead of legacy ``py.path.local``. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -163,22 +163,35 @@ def addini( | |
name: str, | ||
help: str, | ||
type: Optional[ | ||
"Literal['string', 'pathlist', 'args', 'linelist', 'bool']" | ||
"Literal['string', 'paths', 'pathlist', 'args', 'linelist', 'bool']" | ||
] = None, | ||
default=None, | ||
) -> None: | ||
"""Register an ini-file option. | ||
|
||
:name: Name of the ini-variable. | ||
:type: Type of the variable, can be ``string``, ``pathlist``, ``args``, | ||
``linelist`` or ``bool``. Defaults to ``string`` if ``None`` or | ||
not passed. | ||
:default: Default value if no ini-file option exists but is queried. | ||
:name: | ||
Name of the ini-variable. | ||
:type: | ||
Type of the variable. Can be: | ||
|
||
* ``string``: a string | ||
* ``bool``: a boolean | ||
* ``args``: a list of strings, separated as in a shell | ||
* ``linelist``: a list of strings, separated by line breaks | ||
* ``paths``: a list of :class:`pathlib.Path`, separated as in a shell | ||
* ``pathlist``: a list of ``py.path``, separated as in a shell | ||
|
||
.. versionadded:: 6.3 | ||
The ``paths`` variable type. | ||
|
||
Defaults to ``string`` if ``None`` or not passed. | ||
:default: | ||
Default value if no ini-file option exists but is queried. | ||
|
||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. lets put in a DeprecationWarning while at it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should handle all of the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I was thinking we collect them all together in one place https://docs.pytest.org/en/stable/deprecations.html.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @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, im happy to leave the particular warnings out and defer the warning topic for later There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, thanks. I'll try to work on the coordinated py.path deprecation today or tomorrow. We still have the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I missed this review completely, but wanted to comment on this:
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. |
||
self._inidict[name] = (help, type, default) | ||
self._ininames.append(name) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this is copy/paste from branch above