Open gramster opened 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.
@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?
Going to start with just django-stubs. See if that can dynamically download, then add more later.
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?
Yes, I think that would be possible. I'll do that as a second step.
This is partially implemented. Just for Django. Enabling an experiment to see if we get any complaints or problems with the idea.
Next steps:
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?
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.
And this would only be for certain cases. Most would use the 'global' cache location.
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.
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.
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.
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.