[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
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing,
edgar . soldin <=
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, Michael Terry, 2014/05/13
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, edgar . soldin, 2014/05/13
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, Michael Terry, 2014/05/17
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, edgar . soldin, 2014/05/18
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, Michael Terry, 2014/05/18
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, edgar . soldin, 2014/05/18
- Re: [Duplicity-talk] [Duplicity-team] Python 2.6.0 testing, Michael Terry, 2014/05/18