Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
On 8/03/2008, at 8:06 AM, macports-dev-request@lists.macosforge.org wrote:
Date: Sat, 8 Mar 2008 00:22:42 +0900 From: js <ebgssth@gmail.com> Subject: Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't To: "Markus Weissmann" <mww@macports.org> Cc: MacPorts Developers <macports-dev@lists.macosforge.org>
Apparently more people like this change. I'll get back to trac ticket and start working on this.
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. Why are you proposing to explicitly *downgrade* python24, instead of *upgrading* 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. derek.
Hi Derek, Thanks for your feedback. My intention was to make python24 and python25 looks the same as possible, not to downgrade python24. I thoguht I would be confused if I upgraded python port from 2.4 to 2.5 and found that I cannot import zlib anymore. Yes, this is an FAQ but the thing is python24 and python25 don't have the same policy. However, I think you're right. This change would likely break existing systems badly. And I must confess I didn't expect there're people using MacPorts for enterprise. To lower this risk, I could resign python24 port to separate some of its standard modules and add them as dependencies, but I doubt you would like this idea. Thanks. On Mon, Mar 10, 2008 at 4:30 AM, Derek Harland <derek@chocolate-fish.com> wrote:
On 8/03/2008, at 8:06 AM, macports-dev-request@lists.macosforge.org wrote:
Date: Sat, 8 Mar 2008 00:22:42 +0900 From: js <ebgssth@gmail.com> Subject: Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't To: "Markus Weissmann" <mww@macports.org> Cc: MacPorts Developers <macports-dev@lists.macosforge.org>
Apparently more people like this change. I'll get back to trac ticket and start working on this.
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.
Why are you proposing to explicitly *downgrade* python24, instead of *upgrading* 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.
derek.
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
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.
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.
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. Rainer
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
On 11/03/2008, at 3:43 AM, js wrote:
Hi Derek,
Thanks for your feedback.
My intention was to make python24 and python25 looks the same as possible, not to downgrade python24. I thoguht I would be confused if I upgraded python port from 2.4 to 2.5 and found that I cannot import zlib anymore.
Yes, that may be confusing. But it seems that your solution is to make everyone that runs a port upgrade python24 discover they don't have zlib anymore. Thats all I'm pointing out. It also presumably involves you running through every py-* port and discovering whether they depend on zlib etc (at least I hope it does)
To lower this risk, I could resign python24 port to separate some of its standard modules and add them as dependencies, but I doubt you would like this idea.
I'm fine with that as it won't break existing installations. But it doesn't solve your original gripe ... that people can install python24 and have zlib, and then install python25 and not have zlib. [Which I'm not sure is that great an issue] des.
Yes, that may be confusing. But it seems that your solution is to make everyone that runs a port upgrade python24 discover they don't have zlib anymore. Thats all I'm pointing out.
That would be avoidable without any hassle. depend_lib or ui_msg?
It also presumably involves you running through every py-* port and discovering whether they depend on zlib etc (at least I hope it does)
I think you're right.
To lower this risk, I could resign python24 port to separate some of its standard modules and add them as dependencies, but I doubt you would like this idea.
I'm fine with that as it won't break existing installations. But it doesn't solve your original gripe ... that people can install python24 and have zlib, and then install python25 and not have zlib. [Which I'm not sure is that great an issue]
If I add zlib dependency to python24, I'd also add it to python25.
The benefit is that python24 and python25 both uses almost same standard mods. Please note that I'm not sure adding this dependency is good thing. I just wanted to say keeping python ports similar would preferable, in my opinion. On Wed, Mar 12, 2008 at 6:12 AM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
If I add zlib dependency to python24, I'd also add it to python25.
But if you you add it as dependency, what is the benefit from putting it in its own port?
Rainer
I think it's about a time to decide how we handle this. I wanted to change python24 to be python25-like design for consistency. Derek disagreed this idea from python24 users standpoint. Rainer seemed to agree with me, but might not like adding dropped mods to python port as dependencies. Options: 1. Change python24 to drop standard mods just as python25 does. 2. Don't change anything. 3. 1+add dropped mods to python24 and python25 as dependencies I like the first one. How about you? On Wed, Mar 12, 2008 at 10:08 PM, js <ebgssth@gmail.com> wrote:
The benefit is that python24 and python25 both uses almost same standard mods. Please note that I'm not sure adding this dependency is good thing. I just wanted to say keeping python ports similar would preferable, in my opinion.
On Wed, Mar 12, 2008 at 6:12 AM, Rainer Müller <raimue@macports.org> wrote:
js wrote:
If I add zlib dependency to python24, I'd also add it to python25.
But if you you add it as dependency, what is the benefit from putting it in its own port?
Rainer
participants (3)
-
Derek Harland
-
js
-
Rainer Müller