Skip to content
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

pluginmanager does not run consider_module on setuptools plugins #2391

Open
RonnyPfannschmidt opened this issue May 4, 2017 · 11 comments · Fixed by youtux/pypi-notifier-watchlist#3
Assignees
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: infrastructure improvement to development/releases/CI structure

Comments

@RonnyPfannschmidt
Copy link
Member

while turning a local set of modules into a entry-point based pytest plugin i discovered that for based setuptools plugins we dont run consider_module

i'd like to clarify if we want/dont want to do that and how to warn users about that

@hpk42 @nicoddemus ping

@RonnyPfannschmidt RonnyPfannschmidt added type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: enhancement new feature or API change, should be merged into features branch type: infrastructure improvement to development/releases/CI structure status: needs information reporter needs to provide more information; can be closed after 2 or more weeks of inactivity labels May 4, 2017
@nicoddemus
Copy link
Member

I think for consistency it should, unless there's a hidden reason which I'm not aware about.

For quick reference:

    def consider_module(self, mod):
        self._import_plugin_specs(getattr(mod, 'pytest_plugins', []))

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus while looking at it, i really wonder about having a concept of dependent plugin again (in pluggy)

@nicoddemus
Copy link
Member

Hmm how would one declare dependencies in that way? I suppose this dependency mechanism would have to work for both pytest_plugins and setuptools plugins.

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus off hand i took a look at the way setup-tools plugins work, it cant be directly integrated without changing pluggy

@nicoddemus
Copy link
Member

I might have misunderstood your first comment, but I thought you meant to introduce a way for plugins (loaded either by setuptools or the pytest_plugins mechanism) to declare dependencies on other plugins. If that's correct, I'm not sure how plugins declared using pytest_plugins would declare that they depend on other plugins.

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus lets keep the generalized future concept out of the current issue

triggering registration, and being aware of dependencies orders are quite different beasts

as of now py.test has neither, both play into each other, but the triggering of registration should be a lot more simple

@nicoddemus
Copy link
Member

as of now py.test has neither, both play into each other, but the triggering of registration should be a lot more simple

Agreed! 👍

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus as current measure, should we ensure that for all plugin modules we do consider_module ?

that would allow to consolidate various importation details into a plugin registration hook

@nicoddemus
Copy link
Member

as current measure, should we ensure that for all plugin modules we do consider_module ?

IMO definitely.

@RonnyPfannschmidt
Copy link
Member Author

@nicoddemus ok, upcoming pr then ^^

@RonnyPfannschmidt RonnyPfannschmidt removed the status: needs information reporter needs to provide more information; can be closed after 2 or more weeks of inactivity label May 4, 2017
@RonnyPfannschmidt RonnyPfannschmidt self-assigned this May 4, 2017
@nicoddemus
Copy link
Member

That would be in features right? Right on time for 3.1 then. 😉

This was referenced Mar 6, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: backward compatibility might present some backward compatibility issues which should be carefully noted in the changelog type: enhancement new feature or API change, should be merged into features branch type: feature-branch new feature or API change, should be merged into features branch type: infrastructure improvement to development/releases/CI structure
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants