Call the plugin 'jupyterhub'

[minrk]

Typically when we have a pytest plugin package called pytest-jupyterhub, that would mean the plugin name for enabling it would be jupyterhub, not jupyterhub-spawners-plugin (in general, we don't tend to put 'plugin' in the name of plugins).

I think it may be reasonable someday, if we want it, to have separate jupyterhub-spawners that does separate things, but probably not until then.

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[Sheila-nk]

Thanks @minrk for opening this issue.

Yes, I definitely think we should have considered the plugin naming convention. I think we chose the name jupyterhub_spawners_plugin since it'd be easier to associate it with the jupyterhub_spawners module which would contain fixtures for testing spawner implementations. So the idea was to have different modules for different plugins for example a jupyterhub_authenticators module that'd contain fixtures for testing authenticator implementations. All plugin modules would be under the package pytest_jupyterhub.

Would this new change affect the way we've structured the project?

[minrk]

Would this new change affect the way we've structured the project?

It doesn't need to. The plugin name is purely metadata, defined here. To avoid breaking things, we will need to add a 'jupyterhub' plugin that points to the current module (it can be renamed or not, but module name is not related to the pytest plugin name), and then a new, empty module for the previous name should load the jupyterhub plugin and show a deprecation warning to point folks toward the new name. We could rename the jupyerhub_spawners.py to plugin.py if we plan to have only a single plugin here. We do only have generic fixtures so far that would be used in any sub-plugin, anyway.

I think separate plugins for different components may make sense. But there are two separate questions for organization:

• separate modules can help our own internal organization of code. This organization is not really exposed to users, and can change freely
• separate plugins allow users to enable different combinations of fixtures or behaviors

You do need separate modules to have separate plugins, but fewer plugins does not preclude separate modules.

For separate plugins, the question is: would it be helpful for users to enable a subset of our fixtures? Remember, they are mostly only made available, not used unless they have autouse=True or are a dependency of other, used fixtures. So separate plugins would make sense if e.g. they use differently configured hub fixtures, or if there are autouse=True fixtures that might conflict. But otherwise, there isn't much reason to separate them. My inclination is that the same fixtures will be used for everything, and any unused fixtures safely ignored.

What would be useful, and separate for spawners and authenticators, would be if our plugin registered or exposed some standard tests, so that a Spawner could import a test suite and run it to ensure API compliance, assuming some standard fixtures exist (e.g. spawner_class and jupyterhub_config). This may be via a plugin, or it may be via module import. Lacking that, I don't think we need to worry about it right now.