[Biopython-dev] biopython, pip, and Python 3.3 + virtualenv

[Peter Cock]

On Mon, Jul 8, 2013 at 5:18 PM, Laurent Gautier <lgautier at gmail.com> wrote:
> On 07/08/2013 05:00 PM, Peter Cock wrote:
>>
>> On Mon, Jul 8, 2013 at 3:38 PM, Laurent Gautier <lgautier at gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> I just tried installing biopython with pip (v-1.3.1) and Python 3.3
>>> (under a virtual environment created with pyvenv),
>>> but (after a a fairly long time) the process is failing with the last 3
>>> lines printed on the terminal:
>>>
>>> ```
>>>
>>> Python 2to3 processing done.
>>>
>>> running egg_info
>>>
>>> error: error in 'egg_base' option: 'pip-egg-info' does not exist or is
>>> not a
>>> directory
>>>
>>> ```
>>>
>>> Am I missing something ?
>>>
>>> Best,
>>>
>>>
>>> Laurent
>>
>> Hi Laurent,
>>
>> The 2to3 conversion does take a while (sigh), but I have a plan for that:
>> http://lists.open-bio.org/pipermail/biopython-dev/2013-May/010633.html
>
>
> For it is worth, I have started doing the following 2 rules for all Python
> projects (and it is working fairly well):
>
> 1- Develop for Python 3.3 (not worrying about anything earlier in the 3.x
> series)
> 2- When considering support for Python 2, consider 2.7. Forget about
> anything earlier
> The rationale is: if you want the latest version of a package, get a recent
> Python as well. A variant of "you can't have your cake and eat it", I
> suppose. It might seem a bit radical, but that's not that bad; it has worked
> for bioconductor  (where each BioC release depends on the latest R version).

BioConductor's policy of being synced to the R version has pros and
cons, certainly its users are used to this version treadmill.

> If no C-extension is involved, rule #2 is only introducing few conditional
> definitions that are hand-coded. There are only few things to consider.

We're currently doing Python 2.5/2.6/2.6/3.3+ (although for the most
part things have been OK under Python 3.1 and 3.2 as well but we're
not going to officially support those).

We're about to drop Python 2.5, and I'm fairly sure that dual coding
for Python 2.6/2.7/3.3+ will be viable. If not, we may have to be more
aggressive about phasing out Python 2.6 in the near future - we'll see.

>>
>> Which version of Biopython,
>
>
> Latest on Pypi.

https://pypi.python.org/pypi/biopython

That means Biopython 1.61 at the moment, so prior to Brad's
change landing on the trunk (which should be in 1.62 barring
any problems before then).

> I am doing a vanilla:
>
> ```
> pip install biopython
> ```
>
>>   and if from git, which commit?
>
> Anyone on this list volunteering to run `git bisect` on my behalf ?
> (For now I more familiar with Mercurial, and plenty to do at the moment)

Have you tried using the latest Biopython from source to see if Brad's
change fixed this for you? If that also fails the same way, there is no
point to a 'git bisect' ;)

> The distutils/distutils2/distribute/setuptools/whatever can be an endless
> source of headaches. Do you check with one of them in particular ?
> If so, may be worthwhile to enforce the use of that one in setup.py.

Personally I only ever use the stock "python setup.py install" route,
but there has been user demand for things like pip support. I look
forward to improved packaging being standardised in a future
Python 3.x release on day...

Regards,

Peter