Add deprecation warnings for urllib3.contrib.pyopenssl

[sethmlarson]

Minimum requirements

• Create a newsfragment about the deprecation
• Add deprecation warning section to the pyOpenSSL docs
• Emit a DeprecationWarning for urllib3's pyOpenSSL support when importing the urllib3.contrib.pyopenssl module. The deprecation should point to the new docs.
• Add the urllib3-secure-extra dependency to the secure extra
• Emit a DeprecationWarning for urllib3[secure] when it's detected that the urllib3-secure-extra package is importable. The deprecation should point to the new docs.
• Find all issues in the issue tracker about pyOpenSSL and put them in this issue to be closed.

Part of: #2680

[IvanLauLinTiong]

Hi @sethmlarson, quick question for task 5:
Emit a DeprecationWarning for urllib3[secure] when it's detected that the urllib3-secure-extra package is importable. The deprecation should point to the new docs.

Perhaps I miss out something, but I don't see the urllib3-secure-extra package resides here. Thus how do I add the warnings.warn() method on the file ?

[sethmlarson]

@IvanLauLinTiong I uploaded the package urllib3-secure-extra to PyPI not long ago: https://pypi.org/project/urllib3-secure-extra

You'd add this package to our [secure] extra and then if it's importable (via import urllib3_secure_extra) then you know that the [secure] extra was used somewhere.

[IvanLauLinTiong]

@sethmlarson
I see thank you. Will look into this.

[IvanLauLinTiong]

@IvanLauLinTiong I uploaded the package urllib3-secure-extra to PyPI not long ago: https://pypi.org/project/urllib3-secure-extra

You'd add this package to our [secure] extra and then if it's importable (via import urllib3_secure_extra) then you know that the [secure] extra was used somewhere.

Hi @sethmlarson, I managed to add urllib3-secure-extra to secure extra under pyproject.toml. However, I don't understand, how could we yank urllib3-secure-extra with the DeprecationWarning message if we import urllib3_secure_extra ? That's because from file urllib3_secure_extra.py it does not have warnings.warn() implemented or does it?:

Did I miss out something I don't know?

Thanks

[sethmlarson]

@IvanLauLinTiong We wouldn't yank the package, it would only serve as a marker to show that the [secure] extra was installed. Instead of the warning being inside of urllib3_secure_extra module we'd have something like this within urllib3/__init__.py:

try:
    import urllib3_secure_extra
except ImportError:
    pass
else:
    warnings.warn("The urllib3[secure] extra is deprecated ...")

Let me know if this makes sense. Thanks for looking into this!

[IvanLauLinTiong]

@sethmlarson I never thought that we can do it in this try-catch testing way.. Thanks for the pointer.

[IvanLauLinTiong]

All issues in the issue tracker about pyOpenSSL:

• Drop support for OpenSSL<1.1.1 #2168
• Forbid use of cadata arg in pyOpenSSL backend #1885
• Consider supporting ca_certs specified as file-like object #1768
• feature request- capture ip address onto response object #1071
• Planning for breaking changes on TRFKA1.17 #892
• Large POST requests result in SSL3_WRITE_PENDING from urllib3.contrib.pyopenssl#sendall #855
• SSL session reuse not supported #590
• Differences between standard SSL and Pyopenssl (ZeroReturnError, SysCallError) #367

[sethmlarson]

Thanks @IvanLauLinTiong! I'll look to close these issues if they're no longer necessary.

[graingert]

We wouldn't yank the package

Why not?

[sethmlarson]

Because that would break old versions' reproducibility unnecessarily? The break can happen at the time the actual code and extra are removed just as well.

[graingert]

break old versions' reproducibility unnecessarily

A yank isn't supposed to do that

[sethmlarson]

Yanks won't break if you're installing via pip install urllib3_secure_extra==... but that's not how the [secure] extra depends on the package. So if someone was installing via python -m pip install urllib3[secure] (or more likely, was installing a package that had install_requires=["urllib3[secure]"] they would start seeing an error if we were to yank.

[graingert]

Ah I see, I hadn't thought about it that way. I still think you should yank it one day

looking at pypistats will inform what to do, eg you could yank it on Fridays and unyank it on Mondays

[sethmlarson]

Closed in #2701 and #2713.