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

[Laurent Gautier]

On 07/08/2013 06:29 PM, Peter Cock wrote:
> 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.

The package installation system has certainly played a role in help 
keeping users on board.
The life cycle of Python version is much slower, so the pace would be 
slower.

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

IIRC, Python 2.6 does not receive bugfixes for some time already, only 
security fixes (the last of which will be in the autumn).

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

You are missing out on quite a lot, I think.
For example, trying to install the master from github can be achieved 
the following single command:

```
pip install https://github.com/biopython/biopython/archive/master.zip
```

The outcome is the same error as before.


>   I look
> forward to improved packaging being standardised in a future
> Python 3.x release on day...

Some of the time I am thinking that this will not come before Python 4.x...


Best,


Laurent

>
> Regards,
>
> Peter