[Python-Dev] Standard library vs Standard distribution?
On 29/11/2018 22.08, Nathaniel Smith wrote:
> On Thu, Nov 29, 2018 at 10:11 AM Christian Heimes <christian at python.org> wrote:
>> You are assuming that you can convince or force upstream developers to
>> change their project and development style. Speaking from personal
>> experience, that is even unrealistic for projects that are already
>> developed and promoted by officially acknowledged and PSF approved
>> Python authorities.
>> The owners and developers of these projects set their own terms and
>> don't follow the same rigorous CI, backwards compatibility and security
>> policies as Python core. You can't force projects to work differently.
> Python core does an excellent job at CI, backcompat, security, etc.,
> and everyone who works to make that happen should be proud.
> But... I think we should be careful not to frame this as Python core
> just having higher standards than everyone else. For some projects
> that's probably true. But for the major projects where I have some
> knowledge of the development process -- like requests, urllib3, numpy,
> pip, setuptools, cryptography -- the main blocker to putting them in
> the stdlib is that the maintainers don't think a stdlibized version
> could meet their quality standards.
It looks like I phrased my statement unclear. CPython's backwards
compatibility and security policy isn't necessarily superior to that of
other projects. Our policy is just different and more "enterprisy".
Let's take cryptography as an example. I contribute to cryptography once
in a while and I maintain the official Fedora and RHEL packages.
- Alex and Paul release a new version about a day after each OpenSSL
security release. That's much better than CPython's policy, because
CPython only updates OpenSSL with its regularly scheduled updates.
- However they don't release fixes for older minor releases while
CPython has multiple maintained minor releases that get backports of
fixes. That means I have to manually backport security fixes for
cryptography because I can't just introduce new features or API changes
The policy is different from CPython's policy. Some aspects are better,
in other aspects CPython and cryptography follow a different philosophy.