in our last episode, @CaselIT said:

I think this is possible. We could provide a version on pypi, (let's call it 2.0) that has sqlalchemy >= 2 in the requirements.
Then we can continue to publish other non-empty version of the stub using sqlalchemy < 2 as requirements.
Pip should understand these constraints, and newer version of pip will also report if a non compatible version is installed

then @zzzeek said:

also, someone has sqlalchemy 1.4 installed. then they say, "pip install sqlalchemy2-stubs --upgrade". isnt that going to bump their SQLAlchemy to 2.0 ? id rather not have it work that way.

then @CaselIT said:

I think so, but pip will then print an error because of incompatible dependencies

then @CaselIT said:

I think so, but pip will then print an error because of incompatible dependencies

I dont understand. If I install package X which requires Y >= 2.0, it will install Y >= 2.0, im not familiar with what the error would be, unless they have their requirements pinned which is not the norm for development environments.

Also, I'd like the stubs package to be installable, and upgradable in the 1.4 series if not also the 2.0 series, without it printing any errors.

to my mind it seems much simpler to make a new package sqlalchemy-null-stubs and be done with it. advantages include:

1. no "branchy" development with sqlalchemy2-stubs, i.e. we'd otherwise need a "1.4" and a "2.0" branch
2. sqlalchemy-null-stubs doesnt need to be linked to any version anywhere, we can put it on pypi once and then probably not have to ever change it

disadvantages:

1. we have to tell users to change which package they are installing

for the "new sqlalchemy2-stubs" version I'm not understanding yet how that would work so i need to understand that first.

I would have to do some tests, but from memory I think pip does this.
I had not considered the --upgrade that will also update other packages.

after some discussion with typing developers this approach won't be necessary, nor does it work in any case (type checkers always fall back to typeshed when the stubs are missing some module). When SQLAlchemy 2.0 is released, typeshed will remove SQLAlchemy stubs from their project which will resolve the issue for the downstream typecheckers.