-
Notifications
You must be signed in to change notification settings - Fork 127
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
support the creation fo an actual plugin dependency tree and use its root for consideration/order #51
Comments
@RonnyPfannschmidt wait doesn't #52 provide a way to address this? We can temporarily register |
@tgoodlet #52 is absolutely dependent on this actually after all temporary registrations imply sub-registrations of dependent plugins, and a context-manager is also not always desirable (in particular when plugins that add hooks come into play) basically managing dependencies and dependent plugins is required in order to make something like the context manager sustainable |
@RonnyPfannschmidt do we have an example of this being a problem?
@RonnyPfannschmidt I was thinking about this a tiny bit. I guess I'm looking for a deeper explanation of the problem ;) |
@tgoodlet the graph of plugin dependencies cant be drawn with the metadata python packaging provides atm even more so if there is implicit and/or indirect dependence, currently we simply have no way to express the metadata needed to do it |
@RonnyPfannschmidt If you can give me an example of this problem it'd be super helpul ;)
Mostly I just need to have an idea of what ^ consists of. |
@tgoodlet any conftest that puts plugins into pytest_plugin enables them globally instead of for that folder tree |
Hi: any progress on this? |
@pombredanne AFAIK nobody has taken the time to work on this, I'm afraid. |
ack, thanks. I would need something like this, so I may hack a few things that may be of reuse. TBD! |
We always enjoy the help @pombredanne! |
@tgoodlet I have something working mostly on my side that I will push in a branch of scancode-toolkit soon. But in doing I found out that I may use only a few capabilities of pluggy. In particular I do not use pluggy to run the plugins, only as a registry. And my plugins are using Click for the CLI "UI". The way dependencies are expressed is on other plugins is that each plugin holds a list of
So all in all, it may be of little value for pluggy and pytest. And frankly I have no idea on how dependencies are handled by pluggy, though I would be glad to use this. Anyway, I will ping you here when I push this. |
@pombredanne sounds good. |
So I am making some slow progress aboutcode-org/scancode-toolkit#885 in a branch. I have now --with great shame-- realized that I am only using pluggy as a glorified setuptools entrypoint loader and do not use any of the hooking execution mechanisms. My plugins are classes and not functions :| Nevertheless I need to resolve deps between plugins and each of my plugins will need some try fist and try last and this with deps creates some graph. So here is my question 1.
And 2:
|
|
@RonnyPfannschmidt ok, thanks! So there is no special mechanism to express deps for a given hook (except for code and setup-level deps) ? just Now on my side, I want to state explicitly that a plugin depends on another plugin to run. Here is the sketch for me:
|
@pombredanne currect, thats the state of things as they are, note that tryfirst/trylast may sort different hooks of plugins into different locations, and hookwrappers also sort different than normal plugins in addition "historic hooks" also behave differently |
@RonnyPfannschmidt so if you were to offer a way in pluggy to define dependencies between plugins (and I guess primarily in pytest) how and where would these be stated? |
For the sake of clarity even if this is a repeat I am NOT talking about implicit code-level deps (e.g. from an I am talking about runtime deps expressed between plugins to determine if and when a plugin should run given a running context when their code is already importable. |
@pombredanne honestly - no idea yet - i didn't work into the topic of expressing this topology, in particular since the effects on the details i mentioned are so tricky |
@RonnyPfannschmidt fair enough. I will keep trucking on my implementation then in anycase. And if and when you come down to adding this kind of deps to pluggy/pytest, it may give you some practical examples at the minimum. One of the specific of my implementation --beside using Click for CLI-- is that I use multiple setuptools And I do not make use of naming conventions for plugin callables (e.g. prefixing function names with So my high level processing is:
As examples, this is a simple plugin that returns the URLs found in a file. its "hook" is the |
Just wanted to link to pytest-dev/pytest#3084 as a related deprecation due to this limitation. |
in pytest when we use conftests with pytest_plugins,
those specifications are not disabled when using other paths
as such, as soon as trees of conftests that use pytest_plugins, we get a inconsistent dependency state of plugins
additionally some plugins dod epend on other plugins either optionally or directly
experiments and a larger discussion are needed to give this issue the required detail for concrete action
The text was updated successfully, but these errors were encountered: