duplicity-team team mailing list archive

[edgar.soldin@xxxxxx]

On 11.05.2014 20:47, Michael Terry wrote:
> 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.
> 
SNIP

i had a trial myself. but without any special helper. works out similarily easy. this way everything wrt. local python is under /usr/local/python-prefix and there is no need for virtual environments or such.

# install python
wget https://www.python.org/ftp/python/2.7.6/Python-2.7.6.tgz
tar xvf .. ; cd Python-2.7.6/ ; 
./configure --prefix=/usr/local/python-2.7.6
sudo make install

# from here on the new python knows it's location,
# so using to run setup.py will install py libs only there

# install pip (for easy python lib fetching)
## get-pip.py did unfortunately fail because of some SSL cert issue
## /usr/local/python-2.7.6/bin/python get-pip.py 
# needs setuptools first
wget https://pypi.python.org/packages/source/s/setuptools/setuptools-3.6.tar.gz
tar xvf .. ; cd setuptools-3.6/
sudo /usr/local/python-2.7.6/bin/python setup.py install
# now install pip
wget https://pypi.python.org/packages/source/p/pip/pip-1.2.1.tar.gz
tar xvf .. ; cd pip-1.2.1/
sudo /usr/local/python-2.7.6/bin/python setup.py install

# now lockfile is easily fetchable via
sudo /usr/local/python-2.7.6/bin/pip install lockfile

all of this happened on the old OpenSUSE 11 machine.

> 
> == 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:
> 
SNIP
> 
> == 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:

thanks :).. but still a huge favor for users as well. who wants to doublecheck revisions when actually just wanna use software.

> 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.

who would want to install old runtimes except devs in need to support older environments.
 
> == 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.

indeed. also, urlparse is a quite lightweight piece of code and we will find (or have) a way to deal with this incompatibility.

another issue are libs like gpginterface.py where there is no maintained version floating around.

> 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.

looking forward to it.. ede