search

microsoft / pylance-release

Documentation and issues for Pylance
Creative Commons Attribution 4.0 International
1.7k stars 770 forks source link

Offer to install type stub packages for users #3702

Open gramster opened 1 year ago

gramster commented 1 year ago

For some set of blessed packages that we know have well maintained corresponding stub packages on PyPI, we should detect that the user is using the package and offer to install the stub package.

debonte commented 1 year ago

We could also do this automatically for the user rather than prompting them. This would mean downloading the stub in the background to a pylance cached location.

rchiodo commented 1 year ago

@luabud I'm going to try doing the auto-download version of this to see how it goes. Meaning there wouldn't be any GUI changes for this, so it shouldn't need a spec? Do you think the auto-download into a cached location is enough of a spec for this?

rchiodo commented 1 year ago

Going to start with just django-stubs. See if that can dynamically download, then add more later.

debonte commented 1 year ago

Would be great if we could use this to download stubs for SQLAlchemy 1.x users. Currently we have our own bundled SQLAlchemy stubs from python-type-stubs and typeshed also includes some. See https://github.com/microsoft/python-type-stubs/pull/276

Can we strip SQLAlchemy out of our bundled version (seems like we'd want to do that in Pyright also now that SQLAlchemy 2.0 is out) and then use this feature to download them as necessary?

rchiodo commented 1 year ago

Yes, I think that would be possible. I'll do that as a second step.

rchiodo commented 1 year ago

This is partially implemented. Just for Django. Enabling an experiment to see if we get any complaints or problems with the idea.

Next steps:

debonte commented 1 year ago

Download sqlalchemy stubs for SqlAlchemy 1.x

Didn't we decide not to do this because the same stubs would be used for SQLAlchemy 2.x and degrade the experience there?

Could we download them to a workspace-specific location? The typings directory?

rchiodo commented 1 year ago

Could we download them to a workspace-specific location? The typings directory?

That might work but I don't like that we'd be exposing our implementation to the user. Maybe instead we could have a per workspace cache for certain scenarios. That cache could still be written in the pylance\dist folder, but there'd be a subfolder per workspace.

rchiodo commented 1 year ago

And this would only be for certain cases. Most would use the 'global' cache location.

rchiodo commented 1 year ago

Having second thoughts about this. Downloading is messy. And downloading when the package is already there is usually too late. User might start writing code for a package long before they actually run the code.

We'd have to download when they:

Did some investigation on the size of the bundled stubs.

We bundle 12 different packages right now and it comes out to 1.8MB on disk. My guess is nobody would notice until we got into 10s of MBs.

So assuming an average compressed size is .15MB per package, we could theoretically bundle a 100 best known stubs before anybody really cared.

Bundled stubs are better for a number of reasons:

Moving back to triage. Maybe the better solution here is to just bundle more stuff.

rchiodo commented 1 year ago

The use case of downloading stubs per workspace so that SQLAlchemy 1 can work seems like a one off. If we really need to support that we could special case using SQLAlchemay stubs only when SQLAlchemy is not 2.0 or higher.

rchiodo commented 1 year ago

Switching this to be what @gramster originally asked for. Have an action to just install type stubs in the current envrionment.

Whether or not this uses pip/poetry/conda complicates things, but maybe for now we can just have it work for venv environments.

It would also have an 'allowed' list of stubs we know work. Like SQLAlchemy 1.0 stubs.