On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
I'm not a big fan of it either, but it's the way sustainable commercial open source distribution works in practice:
While it's inevitable that redistributors have to deviate from upstream, in Debian and Ubuntu, we really try to keep that at a minimum. Debian, of course is an all volunteer organization so our "customers" are just normal users who I think want an experience as close to installing from source as possible, consistent with the principles and policies of the Debian project. Debian at least tries to document the handful of deviations from upstream.
Likewise in Ubuntu, we try to keep deviations from Debian at a minimum, and document them when we must deviate. Ubuntu is a community driven distro so while Canonical itself has customers, it's much more likely that feedback about the Python stack comes from ordinary users. Again, my personal goal is to make Python on Ubuntu a pleasant and comfortable environment, as close to installing from source as possible, consistent with the principles and policies of the project.
All this to say that IMHO, solutions to problems should go as far upstream as possible. Guidelines certainly are useful (e.g. PEP 394) to maintain consistency across downstream providers where the decisions are primarily in the sphere of influence of the downstreams, but IMHO there's still more that upstream can do to promote PEP 493.
Different redistributors have different customer bases, which also differ from the audience for upstream python.org releases, so saying "don't patch Python" is denying the reality of the obligations commercial vendors have to their customers, while "when you patch Python, please ensure you abide by these guidelines" is something redistributors can realistically do.
ISTM that the same forces are in play regardless of whether the change is in code or in an informational PEP. Best to get consensus where possible, and manifest those decisions in code, but if competing goals are the outcome of a code change or informational PEP, downstream consumers will still make what they judge to be the best decision in the interest of their users, balanced against their own competing constraints.
In this particular case, the migration problems were already raised in the PEP 476 discussions, and the decision was made to *not* provide a public API specifically for globally turning off HTTPS certificate verification, since that would either:
- Need to be added to Python 3 and maintained indefinitely; or
- Be implemented in Python 2.7 only, and thus create another barrier
to 2->3 migration
A minor one, for sure. It wouldn't significantly bother me if the API were underscore-prefixed as a big honkin' clue about the guarantees being made.
- Robert Kuska came up with a way to do a backwards compatible
backport of PEP 476 to RHEL 7.2 that doesn't raise any new barriers to migrating from Python 2 to Python 3
I'm not sure I agree with that. If you have to set an environment variable to get your application to work in Python 2.7, it's *still* a migration issue when you move to Python 3. You're just moving the change out of the code and into the environment, where it's arguably more difficult to re-discover down the road.