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

Load plugins using pip-installable entry points #4734

Closed
wants to merge 1 commit into from

Conversation

chadrik
Copy link
Contributor

@chadrik chadrik commented Mar 14, 2018

Quick first draft to start the conversation about #3916.

This relies on setuptools entry_points to register a loader function, and pkg_resources to access the loader function.

An example registration would look like:

from setuptools import setup

setup(
    entry_points={
        'mypy.plugins': [
            'my_plugin = my_module.mypy_plugin:get_plugin_class'
        ]
    }
)

As with the current config-based approach, the function identified by the entrypoint should take a single string argument which is the mypy version and return a Plugin class.

Let me know what you think.

@JukkaL
Copy link
Collaborator

JukkaL commented Mar 14, 2018

The plugin API isn't yet at all stable so this feature could result in plugins that only work with a specific (potentially old) version of mypy, which would be a problem as it could slow down adoption of new mypy releases.

We could partially work around this by having semantic versioning for the plugin API, but for that to make sense we'd need to declare which parts of internal APIs are public and can be relied on by plugins, since plugins get easy access to mypy internals that we have no intention of including in a stable API.

So for this to make sense as a supported feature, we'd likely need at least these things:

  • Document the plugin API and explicitly enumerate which parts of internal APIs can be relied on.
  • Implement semantic versioning for the plugin API and document the history of changes in the plugin API to make it easier to keep plugins up-to-date.
  • Allow plugins to decide which versions of the mypy plugin API they support.

Maintaining a public plugin API would add some extra maintenance work. It's not clear yet when we are ready to commit to something like this.

Another consideration is mypy startup performance -- using pkgresources as in this PR seems to add about 100msec to mypy startup on my laptop, which would be unfortunate, as I'd rather like to make mypy start up faster in the long term. I expect that this can be made faster, but it would likely require some extra effort.

So unfortunately it seems a bit too early for a feature like this. For now, if you want to make a plugin easily accessible for mypy users, it needs to be maintained in the mypy repository and shipped with mypy. This clearly is not optimal, since the mypy core team needs to review all plugins.

@emmatyping
Copy link
Collaborator

I look forward to the day when this is possible, but the API is not ready as laid out by Jukka above, and further more I'd like to see an alternative to pkg_resources for something like this ideally (perhaps built on importlib.resources?). Until the API is more stable, closing this, though thank you for the proposed changes @chadrik.

@emmatyping emmatyping closed this Mar 27, 2018
@JukkaL
Copy link
Collaborator

JukkaL commented Mar 27, 2018

Yeah, unfortunately we are not ready for this yet. Note that my above comment about startup speed should be taken with a grain of salt, since my measurements may be off the mark.

@emmatyping
Copy link
Collaborator

Note that my above comment about startup speed should be taken with a grain of salt, since my measurements may be off the mark.

It isn't just you, pkg_resources is notorious for being rather slow on import.

(mypyenv) [ethanhs@towerofart mypy]$ time python -c "import pkg_resources"

real    0m0.121s
user    0m0.104s
sys     0m0.017s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants