Tests: Add the EntryPointManager exposed as entry_points fixture
#5656
Conversation
sphuber
force-pushed
the
feature/5655/entry-points-fixture
branch
2 times, most recently
from
bbb8ede to
8ac7b9a
Compare
| def test_entry_points_add_invalid(entry_points): | ||
| """Test the :meth:`EntryPointManager.add` method.""" | ||
| with pytest.raises(TypeError, match='`entry_point_string` should be a string when defined.'): | ||
| entry_points.add('some.module:SomeClass', []) |
There was a problem hiding this comment.
After adding to the entry point, should it be cleaned after the test?
There was a problem hiding this comment.
In this case it wouldn't even be added, because the add call is invalid and an exception is thrown. But even if it would have been valid and an entry point would be added, the cleanup is done automatically by the fixture. The actual entrypoints are monkeypatched by the fixture, so by the time the fixture goes out of scope (i.e. after the tests) the original entry points are simply restored.
sphuber
force-pushed
the
feature/5655/entry-points-fixture
branch
2 times, most recently
from
da63a8b to
4f712b4
Compare
| return module_entry_point.eps() | ||
|
|
||
| @staticmethod | ||
| def _validate_entry_point(entry_point_string: str | None, group: str | None, name: str | None) -> tuple[str, str]: |
There was a problem hiding this comment.
Is entry_point_string exclusive with group and name, I guess only entry_point_string should be enough?
There was a problem hiding this comment.
Indeed, you only need either entry_point_string, or both group and name. Sometimes it is more convenient to pass the group and name separately and not have to do something like f{group}:{name} yourself.
| self, | ||
| value: type | str, | ||
| entry_point_string: str | None = None, | ||
| *, |
There was a problem hiding this comment.
The * operator signifies that all arguments after that are keyword-only arguments, i.e., they can only be specified using keywords. See this PEP. This is useful for this interface where group and name are mutually exclusive with entry_point_string. With this syntax a user calls either
entry_points.add('aiida.parsers:core.base')or
entry_points.add(group='aiida.parsers', name='core.base')There was a problem hiding this comment.
I see, thanks! Then maybe also use this for _validate_entry_point for the exclusive reason I mentioned above?
There was a problem hiding this comment.
The _validate_entry_point is just an internal private method to perform the validation. That is also the reason I didn't use the * method, since here it is not really necessary since only the class itself is calling this. No real point then to add it here.
This fixture allows to easily add or remove entry points for the scope of the function. It temporarily manipulates the content of the entry point cache as provided by `importlib.metadata.entry_points`. After the test function ends, the additions and removals are undone. The `SelectableEntryPoints` class fully implements the dictionary interface which we use to update its state, however, this interface is deprecated. The methods that replace it though, the `select` method, are read-only and do not allow to modify the state, so we cannot use them. To not flood the logs with deprecation warnings, they are intentionally suppressed.
sphuber
force-pushed
the
feature/5655/entry-points-fixture
branch
from
4f712b4 to
338d50d
Compare
You can see an example of how I use it in the tests of the You can see that I define a monitor just above the test, and then use the |
Fixes #5655
This fixture allows to easily add or remove entry points for the scope
of the function. It temporarily manipulates the content of the entry
point cache as provided by
importlib.metadata.entry_points. After thetest function ends, the additions and removals are undone.
The
SelectableEntryPointsclass fully implements the dictionaryinterface which we use to update its state, however, this interface is
deprecated. The methods that replace it though, the
selectmethod,are read-only and do not allow to modify the state, so we cannot use
them. To not flood the logs with deprecation warnings, they are
intentionally suppressed.