duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

Hey Ken and Ed!  Here's a long email.  :)  The dry bits up front, the
discussion stuff lower down.

== Installing Old Pythons ==

The easiest solution I found was pythonz, which is an way to download and
install any version of python into your $HOME.

I had to patch it to work with 2.6.0 <-> 2.6.6, so these instructions will
use my branch that hasn't yet been merged into trunk:

cd /tmp
git clone https://github.com/mikix/pythonz.git
cd pythonz
python ./pythonz_install.py

This will install everything it needs into ~/.pythonz.  Next, add the
following to the end of your ~/.bashrc:

[[ -s $HOME/.pythonz/etc/bashrc ]] && source $HOME/.pythonz/etc/bashrc

(and either re-source ~/.bashrc or open a new terminal for that to take
effect)

Now you can run these commands to download any specific version of python
(note that python 2.6.0 is called just "2.6"):

pythonz install 2.6
pythonz install 2.6.3
etc

These will be installed to ~/.pythonz/pythons/CPython-2.6*

== Testing using pythonz ==

In Ubuntu 14.04 (and maybe other distros?), the version of pip that is
bundled with virtualenv does not work with early 2.6 versions.  So you need
to point tox at its own virtualenv copy that it only normally uses for
py24/py25:

PYTHONPATH=/usr/share/pyshared/tox/vendor

And we want to point tox at the version of Python we installed.  So to
point at 2.6.0 (assuming you don't have python2.6 installed elsewhere on
PATH):

PATH=$PATH:/home/mike/.pythonz/pythons/CPython-2.6/bin

So putting that together:

PYTHONPATH=/usr/share/pyshared/tox/vendor
PATH=$PATH:/home/mike/.pythonz/pythons/CPython-2.6/bin tox

And to test against any other 2.6.x, it's just a small edit to the PATH
line.

You could also point virtualenv at the locally installed python, but I was
content with the command lines above.

== Minimum Python ==

It's probably not all that much work to maintain 2.6.0 now that we can
easily test it (and the differences between it and later 2.6.x versions are
*presumably* few despite us already stumbling on one).

Plus Ed is on 2.6.0.  So that's worth supporting.  :)  But FYI these are
the versions of py26 in the oldest available (common long-term-support)
distros that have a py26 at all:

Version of py26 in Ubuntu 10.04 LTS: 2.6.5
Version of py26 in Debian oldstable: 2.6.6
Version of py26 in RHEL6: 2.6.6

I'm not pushing to drop support for py26 <2.6.5, just noting that it's
getting hard for users to acquire those lower py26 versions.

== Bundling vs External Dependencies ==

Because of the recent quirks with urlparse, there was talk of bundling it
back in again.  Which is a fair question.

It's always a trade-off of maintenance cost vs predictability.  But I admit
to being strongly biased in favor of reducing the lines of code we maintain
in favor of external dependencies.

A) I'm a distro guy and we tend to view the world as a bunch of
interlocking pieces, where the overhead of making them fit together is just
the cost of business.

B) I'm in the middle of the "make duplicity also work in py3" project.
There's a reason one of the first things I did was remove code that could
be depended on elsewhere.  Making little tweaks like that to borrowed code
makes it much harder to update the code later from wherever we got it.
Which means we have to manually backport bugfixes and features.

I'm happy to continue the work of making duplicity work with the various
pythons we support.  It's all part and parcel of the py3 work, making sure
that all the changes I make are backwards compatible.

-mt