plugin system

[DetachHead]

eg. a plugin for pytest

[SIGSTACKFAULT]

Anything I (or anyone else, really) can do on this? Would love to use this but at work i hack on nothing but pytest all day, so i'm stuck with Jedi.

[DetachHead]

my idea for this was to just have people write plugins in typescript

but the bigger issue is probably that it would require exposing a lot of the pyright internals as a public facing api where backwards compatibility needs to be considered with each update. most pyright releases will probably introduce some breaking changes to what we would need to consider a public api

[NCBM]

An idea: Maybe we can consider it from the aspect of plugins - what functions or capabilities would be provided for plugins, such as:

• getting/locating/inserting expressions/codes
• getting/setting the type of an expression
• adding extra fixes for various magical things
• providing completions and/or code actions
• reporting diagnostics
• providing external modules like cython pyx or something else
• etc.

For example:

• "based" features: maybe it's another way to keep compatibility and flexibility?
• pytest: what to integrate and communicate with? fixes of type info, coverage info and/or something more?
• etc.

Then we may consider the difficulty of converting pyright internal implementations into the new extensive APIs and have a draft for these works.

[DetachHead]

i'm thinking what we'll do is try to implement first party support for pydantic (#1505) and pytest but try to isolate them as separate "plugins" within the basedpyright codebase, before we think about creating a public plugin api. this will allow us to support these tools without having all those issues blocked by this one.

then in the future as the system evolves we can consider exposing it as a public api so that people can create their own plugins. but for the forseeable future they will probably just live in this repo. that way we don't have to worry about breaking changes to the plugin system as it's still being developed.