Https and proxy support in urllib2

[Martin Pool]

2009/8/7 John Arbash Meinel <john at arbash-meinel.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Toshio Kuratomi wrote:
>> On 08/05/2009 08:18 PM, Martin Pool wrote:
>>> 2009/8/6 Toshio Kuratomi <a.badger at gmail.com>:
>>>> The important facts from the bottom of that page are that RHEL5 is
>>>> supported until March 31, 2014 and that RHEL6 isn't out yet.
>>> So what should we conclude from that?
>>>
>>> Perhaps that even development releases should work on python2.4 for a
>>> bit longer, at least until RHEL6 is out and until other important
>>> platforms have also moved forward?
>>>
>> This is what I would favor as an end user.  As even more of an end-user,
>> I'd put heavy emphasis on the "at least".  Some platforms move forward
>> at a slow pace because the people who install them want to follow a
>> conservative update strategy WRT their OS.  This means that they won't
>> jump to the next release immediately when it comes out.  Meanwhile the
>> people who use the machines that the IT department has installed have a
>> need to move to the latest bazaar because of compatibility with another
>> project or in order to run a new app that only works with the new API.
>> The longer this is possible, the better for the end-user.
>
> Of course, if they are capable of installing the latest bzr, they are
> probably equally capable of installing a newer version of python. Both
> python and bzr can be easily installed inside a user's home directory if
> they don't have system access.
>
> So saying that the latest of X needs to run on a really old Y because
> then it can be installed on this un-updated system, is a bit of a stretch.

If you look at Canonical's IS processes: developers can install what
they want on their own machines but servers are fairly locked down.
Only a subset of sysadmins can install software and they always
install from debs (even if they have to build the debs themselves.)
Getting a new bzr installed by backporting in pretty easy; getting a
new Python not so much because of the nontrivial interactions between
the interpreter and dependent packages.  So it would be laborious if
our team started requiring a bzr that needs a Python later than the
latest supported server OS release.

And even then IS departments might not upgrade servers right away, but
at that point I think we need to start telling them just to stay on an
old bzr series.

What I have in mind is that when the major OS platforms all have a
later Python at least in beta, we can look at moving the minimum
requirement forward to that version.

-- 
Martin <http://launchpad.net/~mbp/>