Message-ID: <4B5F54D1.3080400@users.sourceforge.net>
Date: Tue, 26 Jan 2010 14:47:13 -0600
From: "Yaakov (Cygwin/X)" <yselkowitz@users.sourceforge.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: Python 2.6 ?
References: <4B5EADFB.4010200@users.sourceforge.net> <20100126135611.GA2212@tishler.net>
In-Reply-To: <20100126135611.GA2212@tishler.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

On 26/01/2010 07:56, Jason Tishler wrote:
> Agreed, especially since the Python web site indicates the following:
>
>      The current production versions are Python 2.6.4 and Python 3.1.1.

Which raises another point: 3.x are meant to be installed in parallel 
with 2.x (/usr/bin/python3 instead of /usr/bin/python, etc.).  So a 
separate python3 package might also be in order.

> Wow, I didn't realize there were so many Cygwin packages dependent on
> Python:
>
>      $ wget -q -O - http://mirror.nyi.net/cygwin/setup.ini | \
>      grep '^requires:.* python' setup.ini | wc -l
>      54

You think that's a lot?  Ports has another two to three *hundred* on top 
of that.  That's why I want this to be coordinated.

> What do you propose?  Should I release a Python 2.6 as experimental, use
> alternatives, or another approach?

That depends, primarily, if we intend on support more than one 2.x 
version at a time.  Until now, we have not.  (Of course, this does not 
preclude a python3 package, as stated above.)

Either way, I don't think we want to use alternatives, as that means 
that anybody can choose which version is their /usr/bin/python, etc. 
There must only be one default version of Python across the entire 
distro at any given time, otherwise things break.

So if we keep with only one 2.x version at a time, then 2.6.4 as 
experimental is probably the best bet, with a clear schedule to 
maintainers of when 2.6 will go stable so the transition has a chance of 
being smooth.  If, OTOH, we start supporting 2.5, 2.6, and (soon) 2.7 
simultaneously, then the packaging scheme for Python would need to 
significantly change.

While you're at it, could you please include my ctypes patches:

http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python2.6/2.5.2-ctypes-util-find_library.patch
http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/lang/python3/3.0rc3-ctypes-util-find_library.patch

This is critical for typical ctypes usage, where only a library name is 
given (e.g. PyOpenGL).  It means that the -devel package is required, 
but the same is true of the techniques used on Linux.

> BTW, is the threading workaround mentioned in the following post still
> necessary?
>
>      http://cygwin.com/ml/cygwin/2009-07/msg00831.html

Last time I checked, yes for both 2.6 and 3.1.


Yaakov

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple