Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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 [EMAIL PROTECTED] 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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
To lower this risk, I could resign python24 port to separate some of sorry, another typo s/resign/redesign/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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 ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
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. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't (js)
On 8/03/2008, at 8:06 AM, [EMAIL PROTECTED] wrote: Date: Sat, 8 Mar 2008 00:22:42 +0900 From: js [EMAIL PROTECTED] Subject: Re: [MacPorts] #14342: python25 drops modules by default,but python25 doesn't To: Markus Weissmann [EMAIL PROTECTED] 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
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
Apparently more people like this change. I'll get back to trac ticket and start working on this. On Thu, Feb 21, 2008 at 12:39 AM, js [EMAIL PROTECTED] wrote: Thanks for thorough explanation. That makes sense. The reason why I started this discussion is that I want to make python24 to be python25-like port. What if I created patches for this, Would you accept that changes? well, what else do you want to change? There already are py-bsddb, py- readline, .. which provide modules not build by default (by the python24 port). I'd like to drop modules from python24 the same way python25 do currently. This would help writing Portfile for python2[45] easier. If you _really_ don't bother which python you end up with (and it doesn't matter if that changes), then you can use the python_select: port to do just that. It basically provides symlinks to the real executables which you can change by calling python_select(1). Attention: If your port makes note of the exact location of you python executable, this might create an implicit dependency (which will cause breakage if you uninstall the wrong python) No, I don't want default python on MacPorts. Explicit python24 and python25 would be clearer. just wanted to say python-minimal + py25-* ports would be nice. To be honest, I also want to change py- prefix ports to py24- but this plan is rejected recently... Rejected? Most probably due to the amount of work on both the project and the users' side. I think this would be cool, but if someone tackles this: Do a single commit on _all_ renamed ports and ports that depend on those AND write a mail to macports-users@ AND put something on the FAQ how to handle potential breakage. If I prepared patches for this, would you bother to review/accept them? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
Hi Markus, does not compute: python25 drops but python25 doesn't -- contradiction detected. ;) Oops! That's typo. My question was why python2.4 and 2.5 is different. If the question was why python25 does not build all auxiliary modules [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. We had this discussion of which modules would be cool to include by default and which not to already. Conclusion was that either we rename python25 to python25-core and make a virtual port python25 that requires all modules+python25-core OR to make a python25-all (or whatever) port that collects all cool modules by dependency. The former sucks because we would need to change a lot of dependencies and the latter never made it into the repository because nobody cared enough. If someone is keen on getting the former to work: Please fix all dependencies!!! (And please also make this consistent for 2.4 and 3.0) Thanks for thorough explanation. That makes sense. The reason why I started this discussion is that I want to make python24 to be python25-like port. What if I created patches for this, Would you accept that changes? As for python25's design you brought up, I prefer the former, which apparently not your favorite :) The former reminds me of Debian/GNU Linux's python package. The python package is a dependency package which depends on default python, python2.4 and python-minimal. Any chance making this changes? To be honest, I also want to change py- prefix ports to py24- but this plan is rejected recently... ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
On 20 Feb 2008, at 15:48, js wrote: Hi Markus, does not compute: python25 drops but python25 doesn't -- contradiction detected. ;) Oops! That's typo. My question was why python2.4 and 2.5 is different. If the question was why python25 does not build all auxiliary modules [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. We had this discussion of which modules would be cool to include by default and which not to already. Conclusion was that either we rename python25 to python25-core and make a virtual port python25 that requires all modules+python25-core OR to make a python25-all (or whatever) port that collects all cool modules by dependency. The former sucks because we would need to change a lot of dependencies and the latter never made it into the repository because nobody cared enough. If someone is keen on getting the former to work: Please fix all dependencies!!! (And please also make this consistent for 2.4 and 3.0) Thanks for thorough explanation. That makes sense. The reason why I started this discussion is that I want to make python24 to be python25-like port. What if I created patches for this, Would you accept that changes? well, what else do you want to change? There already are py-bsddb, py- readline, .. which provide modules not build by default (by the python24 port). As for python25's design you brought up, I prefer the former, which apparently not your favorite :) The former reminds me of Debian/GNU Linux's python package. The python package is a dependency package which depends on default python, python2.4 and python-minimal. Any chance making this changes? If you _really_ don't bother which python you end up with (and it doesn't matter if that changes), then you can use the python_select: port to do just that. It basically provides symlinks to the real executables which you can change by calling python_select(1). Attention: If your port makes note of the exact location of you python executable, this might create an implicit dependency (which will cause breakage if you uninstall the wrong python) To be honest, I also want to change py- prefix ports to py24- but this plan is rejected recently... Rejected? Most probably due to the amount of work on both the project and the users' side. I think this would be cool, but if someone tackles this: Do a single commit on _all_ renamed ports and ports that depend on those AND write a mail to macports-users@ AND put something on the FAQ how to handle potential breakage. Regards, -Markus -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
Thanks for thorough explanation. That makes sense. The reason why I started this discussion is that I want to make python24 to be python25-like port. What if I created patches for this, Would you accept that changes? well, what else do you want to change? There already are py-bsddb, py- readline, .. which provide modules not build by default (by the python24 port). I'd like to drop modules from python24 the same way python25 do currently. This would help writing Portfile for python2[45] easier. If you _really_ don't bother which python you end up with (and it doesn't matter if that changes), then you can use the python_select: port to do just that. It basically provides symlinks to the real executables which you can change by calling python_select(1). Attention: If your port makes note of the exact location of you python executable, this might create an implicit dependency (which will cause breakage if you uninstall the wrong python) No, I don't want default python on MacPorts. Explicit python24 and python25 would be clearer. just wanted to say python-minimal + py25-* ports would be nice. To be honest, I also want to change py- prefix ports to py24- but this plan is rejected recently... Rejected? Most probably due to the amount of work on both the project and the users' side. I think this would be cool, but if someone tackles this: Do a single commit on _all_ renamed ports and ports that depend on those AND write a mail to macports-users@ AND put something on the FAQ how to handle potential breakage. If I prepared patches for this, would you bother to review/accept them? ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
On Feb 18, 2008, at 9:53 AM, Markus Weissmann wrote: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. Yes! And for those who are banging on a 64-bit Python, we can't touch anything that uses a Carbon API. Like Tk. Has anyone successfully built a 64-bit version of Python 2.5.1 on Macintosh? - boyd Boyd Waters National Radio Astronomy Observaotory New Mexico, USA, Earth ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
There seems to be few people who is interested in this issue :( I really love to fix this for consistency. If somebody asked, I'd do create py25-ports which already exist for python24. python25 should be more used than python24. The more modules python25 has, the more people likely to use python25 I assume.. ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
js wrote: Just out of curiosity, could you tell me why default python25 drops those modoles? I really don't know it, Markus will know more about it. Rainer ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Re: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
On 18 Feb 2008, at 17:27, Rainer Müller wrote: js wrote: Just out of curiosity, could you tell me why default python25 drops those modoles? I really don't know it, Markus will know more about it. does not compute: python25 drops but python25 doesn't -- contradiction detected. ;) If the question was why python25 does not build all auxiliary modules [1] like _sqlite3 etc.: For people who don't need e.g. tk-support, building all those dependencies is unnecessary. We had this discussion of which modules would be cool to include by default and which not to already. Conclusion was that either we rename python25 to python25-core and make a virtual port python25 that requires all modules+python25-core OR to make a python25-all (or whatever) port that collects all cool modules by dependency. The former sucks because we would need to change a lot of dependencies and the latter never made it into the repository because nobody cared enough. If someone is keen on getting the former to work: Please fix all dependencies!!! (And please also make this consistent for 2.4 and 3.0) Regards, -Markus [1] http://trac.macports.org/projects/macports/wiki/FAQ#WhycantIimportfooinPython2.5 -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/ ___ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Fwd: [MacPorts] #14342: python25 drops modules by default, but python25 doesn't
# Moving from Trac ticket #14342
No, py25-foo can have different dependencies than py-foo. I don't know
what you wanted to tell us with this.
I meant if we would change python24 to drop some standard modules like
the current python25 port does, py-foo and py25-foo's dependencies
would be the same.
Not sure this is 100% same but almost the same I assume.
And there is no problem that we have more py-* ports than py25-* ports. We
just add what people request. If nobody needs a port, but it is in the
tree, it is just more work for maintainers. So if you need some port, ask
for it.
No problem, but Python project now recommend users to use python2.5,
not 2.4. Providing a lot of ports to python25 users would encourage users to
use python2.5. Some people don't bother to write reports even if they want.
I like to add more py25- ports to make python25 looks more *atrractive*.
Forwarded Conversation
Subject: [MacPorts] #14342: python25 drops modules by default, but
python25 doesn't
From: MacPorts [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, Feb 16, 2008 at 11:51 AM
#14342: python25 drops modules by default, but python25 doesn't
---+
Reporter: [EMAIL PROTECTED] | Owner:
[EMAIL PROTECTED]
Type: enhancement| Status: new
Priority: Normal | Milestone: Port Enhancements
Component: ports | Version: 1.6.0
Keywords: python |
---+
Python2.5 disables common modules by default, but
python2.4 doesn't. See dports/lang/python25/files/patch-setup.py
{{{
# This global variable is used to hold the list of modules to be
disabled.
-disabled_module_list = []
+disabled_module_list =
[zlib,_hashlib,_ssl,_bsddb,_sqlite3,_tkinter,bz2,gdbm,readline,_curses,_curses_panel]
}}}
IMHO, all python pors should be as similar as they can be.
--
Ticket URL: http://trac.macosforge.org/projects/macports/ticket/14342
MacPorts /projects/macports
Ports system for Mac OS
From: MacPorts [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, Feb 16, 2008 at 11:52 AM
#14342: python25 drops modules by default, but python25 doesn't
+---
Reporter: [EMAIL PROTECTED] | Owner:
[EMAIL PROTECTED]
Type: enhancement| Status: new
Priority: Normal | Milestone: Port Enhancements
Component: ports | Version: 1.6.0
Resolution: |Keywords: python
+---
Comment (by [EMAIL PROTECTED]):
If there's a reason, please make it clear by leaving comments about that
on the patch file.
--
Ticket URL:
http://trac.macosforge.org/projects/macports/ticket/14342#comment:1
[Quoted text hidden]
From: MacPorts [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, Feb 16, 2008 at 12:02 PM
#14342: python25 drops modules by default, but python25 doesn't
+---
Reporter: [EMAIL PROTECTED] | Owner:
[EMAIL PROTECTED]
Type: enhancement| Status: new
Priority: Normal | Milestone: Port Enhancements
Component: ports | Version: 1.6.0
Resolution: |Keywords: python
+---
Comment (by [EMAIL PROTECTED]):
These are provided as seperate ports. For example py25-hashlib, py25-zlib
and others. I don't know what the advantage of that was, but we already
had that discussion once.
Portfile writers should include correct dependencies.
--
Ticket URL:
http://trac.macosforge.org/projects/macports/ticket/14342#comment:2
[Quoted text hidden]
From: MacPorts [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sat, Feb 16, 2008 at 12:18 PM
#14342: python25 drops modules by default, but python25 doesn't
+---
Reporter: [EMAIL PROTECTED] | Owner:
[EMAIL PROTECTED]
Type: enhancement| Status: new
Priority: Normal | Milestone: Port Enhancements
Component: ports | Version: 1.6.0
Resolution: |Keywords: python
+---
Comment (by [EMAIL PROTECTED]):
I think that's OK, but the thing is python24 doesn't drop these modules.
It's a weird...
--
Ticket URL:
http
