You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yup, I started with "real packages", clarified to "PEP 561 packages", but missed editing out the "real". Basically packages that can be arbitrarily big, do complicated setup.py things, be system dependent, yada yada
Not speaking about stubs packages in general, but I think it's reasonable if typeshed packages depend on dependencies of the corresponding upstream package. I.e. if package foo depends on cryptography, it's fine that our foo-types depends on cryptography as well, since it doesn't introduce "new" dependencies. Apart from that we should vet dependencies carefully.
I think that it would be sufficient to maintain an allowlist of vetted dependencies. I'd expect that the number of such dependencies will be fairly small, so it shouldn't be much effort to maintain.
Activity
[-]Remove cryptography (August 2021)[/-][+]Remove cryptography (not before August 2021)[/+][-]Remove cryptography (not before August 2021)[/-][+]Remove cryptography (not before September 2021)[/+]hauntsaninja commentedon Jun 11, 2021
One fun and different thing about types-cryptography is that other typeshed packages depend on it: paramiko, PyJWT, openssl-python.
So we will need to ensure stub packages can depend on non-typeshed-stub-packages.
hauntsaninja commentedon Jun 17, 2021
Just in case, does anyone feel strongly against allowing stub packages from depending on real PEP 561 packages? cc @JukkaL
srittau commentedon Jun 17, 2021
What do you mean by "real" PEP 561 packages?
Akuli commentedon Jun 17, 2021
Perhaps packages that contain
.pyfiles and apy.typedfile.hauntsaninja commentedon Jun 17, 2021
Yup, I started with "real packages", clarified to "PEP 561 packages", but missed editing out the "real". Basically packages that can be arbitrarily big, do complicated setup.py things, be system dependent, yada yada
srittau commentedon Jun 17, 2021
Not speaking about stubs packages in general, but I think it's reasonable if typeshed packages depend on dependencies of the corresponding upstream package. I.e. if package
foodepends oncryptography, it's fine that ourfoo-typesdepends oncryptographyas well, since it doesn't introduce "new" dependencies. Apart from that we should vet dependencies carefully.JukkaL commentedon Jun 18, 2021
I agree with @srittau.
I think that it would be sufficient to maintain an allowlist of vetted dependencies. I'd expect that the number of such dependencies will be fairly small, so it shouldn't be much effort to maintain.
srittau commentedon Aug 24, 2021
Blocked by #5952.
Akuli commentedon Dec 5, 2021
What is the current status of this? Can we now make other packages depend on
cryptography?[-]Remove cryptography (not before September 2021)[/-][+]Remove cryptography (depends on #5952)[/+]