[MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)

[Derek Harland]

On 11/03/2008, at 4:21 AM, Rainer Müller wrote:

> Derek Harland wrote:
>> I'm not sure I particularly like this proposed change.  As I   
>> understand it, you explicitly want to *downgrade* the  
>> functionality  of python24 to make it more like python25, by for  
>> example, removing  hashlib and zlib.
>> I cannot understand the logic of this.  This can only conceivably   
>> break python24 installations.  Even if all existing py-* ports  
>> are  altered to bring in extra required dependencies, peoples  
>> (and  institutions) own proprietary code that previously assumed  
>> the  existence of these standard libraries will break.  And that  
>> will  annoy them greatly.
>
> I don't care about software outside of MacPorts. The user is  
> responsible him-/herself to install the appropriate dependencies  
> for it.

 From my point of view, I can certainly agree that users are  
responsible for doing so upon *installation* of python.  A typical  
user is going to install macports python and then whatever other  
external modules they require.  They are then conceivably going to  
write their own tools, scripts and applications using this python  
environment they have developed for themselves.

The proposal is now that they will run "port upgrade" and in fact  
receive a veritable downgrade of the environment they have crafted.   
Their own code will crash and possibly inexplicably to them ("it ran  
fine the other day ...")

And for what reason will a downgrade be pushed out to all users?   
Because there is an "inconsistency" in the disabled modules.  Does it  
really matter that much?

>
>> Why are you proposing to explicitly *downgrade* python24, instead  
>> of  *upgrading* python25?
>
> The disabled_modules was chosen wisely as Markus and Boyd explained  
> earlier in this thread. I don't see a reason to change python25 again.

My point was more that the problem is "X contains more functionality  
than Y" and the proposed solution is "downgrade X so it looks like  
Y".  In reality I think there is little benefit in changing either of  
python24 or python25.

>
>> I also do not buy into the inference that's been made in this  
>> thread  in the past that more people must be using python25 than  
>> python24.   For institutions with large proprietary codebases (eg  
>> financial  companies), shifting python versions *is* a costly  
>> business that is  not worth the often negligible benefit.  I would  
>> suggest that many  are still running more code off 2.4 than 2.5  
>> (companies I have been  involved with have moved from 1.5->20->2.2- 
>> >2.4->2.6).  I'm not  suggesting many such companies run code on  
>> OSX, but mine certainly is.
>
> Wouldn't it be the responsibility of their sysadmins to test new  
> releases and do upgrades only if it works? It would be their job to  
> install new py-* dependencies if needed.

But this is the point.  It can be a struggle to prove that a large  
developed code base will work across a big number shift in python  
version (2.4->2.5).  Is the expectation now that users should be  
proving all incremental updates of their python24 installation in  
case there's been an upstream downgrade in functionality?

Its inevitable that at times macports will need to break its users  
codebases.  But to break them over a relatively trivial matter like  
this seems overdone.

des