duplicity-talk
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing


From: edgar . soldin
Subject: Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing
Date: Tue, 13 May 2014 14:19:24 +0200
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]