Sorry for not having been paying close attention, but I found I needed python 2.5, so I installed that. I also needed py-crypto, but that has a dependency on python24 and no py25-crypto package was available. So, I fetch'd and extract'd plain ol py-crypto, then with python 2.5 on my PATH I was able to build, test, and install it (into /opt/local/ lib/python2.5/...) and so far it seems to be working fine. --Doug
Hi Douglas, the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released) cheers, -Markus PS: I just submitted a py25-crypto port; On 20.02.2007, at 05:55, Douglas Philips wrote:
Sorry for not having been paying close attention, but I found I needed python 2.5, so I installed that. I also needed py-crypto, but that has a dependency on python24 and no py25-crypto package was available. So, I fetch'd and extract'd plain ol py-crypto, then with python 2.5 on my PATH I was able to build, test, and install it (into /opt/ local/lib/python2.5/...) and so far it seems to be working fine.
--Doug
_______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
--- Markus W. Weissmann http://www.mweissmann.de/
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25? -landonf
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications because suddenly some py-* ports (read py-wxPython (there may be others--I just don't know)) depend on python25 while other py-* ports depend on python24. The Fink developers hashed out this problem a few years back with perl version 5.6 / 5.8 problems and concluded that the only road forward was package duplication. I say duplicate the ports! Although perhaps if we could create a Portfile.in type or style of port that really generates multiple installable ports, we'd have an easy solution... Randall Wood rhwood@mac.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications because suddenly some py-* ports (read py-wxPython (there may be others--I just don't know)) depend on python25 while other py-* ports depend on python24.
Ditto. I am disappointed how the py-wxpython Port has been handled. I based a professional product on the 2.6 version 9 months ago which has shipped and worked great, and when we went to upgrade to HEAD, it doesn't build.
The Fink developers hashed out this problem a few years back with perl version 5.6 / 5.8 problems and concluded that the only road forward was package duplication. I say duplicate the ports!
Well, they don't duplicate ports. You can specify for a single Perl module which versions of Perl the module can be built against: Type: perl (5.8.1 5.8.4 5.8.6 5.8.8) or for Python: Type: python (2.3 2.4 2.5) So there's no code duplication. We should come up for a way for this to be done in MacPorts.
Although perhaps if we could create a Portfile.in type or style of port that really generates multiple installable ports, we'd have an easy solution...
Agreed. Regards, Blair
On 22.02.2007, at 03:54, Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications because suddenly some py-* ports (read py-wxPython (there may be others--I just don't know)) depend on python25 while other py-* ports depend on python24.
The Fink developers hashed out this problem a few years back with perl version 5.6 / 5.8 problems and concluded that the only road forward was package duplication. I say duplicate the ports!
Although perhaps if we could create a Portfile.in type or style of port that really generates multiple installable ports, we'd have an easy solution...
The problem I see here is, that there is code that runs with 2.5 but not with 2.4 (and vice versa). Therefore we would at least need a mechanism for also allowing the "cheap" duplicate ports (for 2.4 and 2.5) as there will be modules that work with 2.4 in version A and only with 2.5 with version B. Could we perhaps somehow specify two port definitions in one Portfile? Or find a good mechanism to include the common parts of two Portfiles from a shared third file? Thoughts? -Markus --- Markus W. Weissmann http://www.mweissmann.de/
On Feb 22, 2007, at 6:15 AM, Weissmann Markus wrote:
The problem I see here is, that there is code that runs with 2.5 but not with 2.4 (and vice versa). Therefore we would at least need a mechanism for also allowing the "cheap" duplicate ports (for 2.4 and 2.5) as there will be modules that work with 2.4 in version A and only with 2.5 with version B. Could we perhaps somehow specify two port definitions in one Portfile? Or find a good mechanism to include the common parts of two Portfiles from a shared third file? Thoughts?
The portgroup code could activate a version-specific variant after detecting the macports installed python version. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On Feb 22, 2007, at 3:15 AM, Weissmann Markus wrote:
On 22.02.2007, at 03:54, Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications because suddenly some py-* ports (read py-wxPython (there may be others--I just don't know)) depend on python25 while other py-* ports depend on python24.
The Fink developers hashed out this problem a few years back with perl version 5.6 / 5.8 problems and concluded that the only road forward was package duplication. I say duplicate the ports!
Although perhaps if we could create a Portfile.in type or style of port that really generates multiple installable ports, we'd have an easy solution...
The problem I see here is, that there is code that runs with 2.5 but not with 2.4 (and vice versa). Therefore we would at least need a mechanism for also allowing the "cheap" duplicate ports (for 2.4 and 2.5) as there will be modules that work with 2.4 in version A and only with 2.5 with version B. Could we perhaps somehow specify two port definitions in one Portfile? Or find a good mechanism to include the common parts of two Portfiles from a shared third file? Thoughts?
We could adapt the "include" mechanism such that one could include other Ports (or meta ports) in the index. "Meta ports" would require some analogue to PortSystem that informed the indexer that it should not index that specific port. -landonf
On 22.02.2007, at 18:35, Landon Fuller wrote:
On Feb 22, 2007, at 3:15 AM, Weissmann Markus wrote:
On 22.02.2007, at 03:54, Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python 2.5 "port group". This will allow us to quickly produce all the python vastness for python 2.5, too. This might be a chance for newcomers to start coding Portfiles: Basically you will have to replace the "GroupCode" line and the name from the python 2.4 module Portfile to get a Python 2.5 one. People with the release candidate of 1.4 installed can already hack away here (just don't put that code into the repository yet - as long as 1.4 is not released)
I'm nonplussed by the massive code duplication that will occur for py25 portfiles -- these will almost invariably be direct copies of the py24 portfiles. I'm not sure of the best solution -- perhaps python portgroup can either point to 24 or 25?
I'm nonplussed (even upset) about broken python applications because suddenly some py-* ports (read py-wxPython (there may be others--I just don't know)) depend on python25 while other py-* ports depend on python24.
The Fink developers hashed out this problem a few years back with perl version 5.6 / 5.8 problems and concluded that the only road forward was package duplication. I say duplicate the ports!
Although perhaps if we could create a Portfile.in type or style of port that really generates multiple installable ports, we'd have an easy solution...
The problem I see here is, that there is code that runs with 2.5 but not with 2.4 (and vice versa). Therefore we would at least need a mechanism for also allowing the "cheap" duplicate ports (for 2.4 and 2.5) as there will be modules that work with 2.4 in version A and only with 2.5 with version B. Could we perhaps somehow specify two port definitions in one Portfile? Or find a good mechanism to include the common parts of two Portfiles from a shared third file? Thoughts?
We could adapt the "include" mechanism such that one could include other Ports (or meta ports) in the index. "Meta ports" would require some analogue to PortSystem that informed the indexer that it should not index that specific port.
This sounds like a good idea - the vim port already does something like this (for it's quite impressive list of patchfiles). This could look like this (for the py-crypto port): - - - common.inc - - - version 2.0.1 categories python security platforms darwin maintainers mww@macports.org description collection of cryptographic algorithms and protocols for python long_description collection of cryptographic algorithms and protocols... homepage http://www.amk.ca/python/code/crypto.html master_sites http://www.amk.ca/files/python/crypto/ distname pycrypto-${version} checksums md5 4d5674f3898a573691ffb335e8d749cd - - - Portfile-py24 - - - PortSystem 1.0 include "common.inc" name py24-crypto PortGroup python24 1.0 - - - Portfile-py25 - - - PortSystem 1.0 include "common.inc" name py25-crypto PortGroup python25 1.0 Those three files could live happily all together in the python/py- crypto directory. The only mechanism we would need for this, is to allow different names for Portfiles (so that two can sit side by side in one place). This solution is also quite nice as you could add a 'version' and 'checksum' key to one of the Portfiles, if e. g. the latest version does not work e. g. on Python 2.4 anymore. This way you could still share the 'description', 'homepage' etc. -Markus PS: This _might_ be a good opportunity to switch from the "Portfile" name as an identifier for a port to something file-extension based, like py25.port and py24.port. --- Markus W. Weissmann http://www.mweissmann.de/
This has been an interesting conversation, particularly given some of the comments from folks claiming they're facing this scenario in commercial / support scenarios where products are based on (presumably forwards incompatible) Python version x and unable to migrate to Python version y. Do such people simply bundle Python with their applications (I've seen that approach used) or do they rely in Framework versioning support? That's mostly good for backwards compatibility but pretty hosed for forwards compatibility since Apple didn't really take the Framework approach to its fullest and there's really no way to say "I want -framework Foo versionX" at the link stage, compiling newer stuff against older bits (you pretty much have to go to the trouble of keeping back-rev'd copies of MacOSX around for hosting your builds). How does MacPorts help people with this, or does it? I ask because we're likely going to go with Python 2.5 for Leopard (not in the seeds yet, but soon) and there's still time to rethink that decision if it's really going to hose people. - Jordan
Jordan K. Hubbard wrote:
This has been an interesting conversation, particularly given some of the comments from folks claiming they're facing this scenario in commercial / support scenarios where products are based on (presumably forwards incompatible) Python version x and unable to migrate to Python version y. Do such people simply bundle Python with their applications (I've seen that approach used) or do they rely in Framework versioning support?
It's not unable to migrate, it's more like, we want to move to the new Python and still support apps written on the old version while we're working with the new version, and maintain two Pythons at the same time until we have all our internal Python modules on the new Python. This is for desktop apps for internal users (non-developers, like artists). And with Python, you can't share binary modules, or it's not recommended to do that. Another use of MacPorts was to build a portable application on a portable Firewire/USB drive with a local MySQL database and PHP web site. In that case, we just put an entire MacPorts build under /Volumes/SOMENAME/MacPorts and then launch MySQL, Apache, and a py-wxwidgets app from there that would talk to MySQL and the web site. We recently changed the mount point name and hence needed to recompile everything and that's when we found the py-wxwidgets breakage. That's mostly good for backwards compatibility but pretty
hosed for forwards compatibility since Apple didn't really take the Framework approach to its fullest and there's really no way to say "I want -framework Foo versionX" at the link stage, compiling newer stuff against older bits (you pretty much have to go to the trouble of keeping back-rev'd copies of MacOSX around for hosting your builds). How does MacPorts help people with this, or does it?
It's not the Python as much, as most modules are easily moved to the new version. It's more, some py-* ports are moved from 2.4 to 2.5, so you have an incomplete set of packages for a Python version. But in our portable application, we built the entire MacPorts into /Volumes/SOMENAME on 10.3 and we run it on 10.4 just fine (even on i386, which is nice).
I ask because we're likely going to go with Python 2.5 for Leopard (not in the seeds yet, but soon) and there's still time to rethink that decision if it's really going to hose people.
No, I would like to see Python 2.5 in Leopard. No better time to move to 2.5. My concerns are just with the MacPorts' Pythons, as for MacPorts, I count on its version of Python, not the OSes. Do you work for Apple? I see your email address as a non-Apple one. Regards, Blair
On 22 Feb, 2007, at 20:29, Jordan K. Hubbard wrote:
This has been an interesting conversation, particularly given some of the comments from folks claiming they're facing this scenario in commercial / support scenarios where products are based on (presumably forwards incompatible) Python version x and unable to migrate to Python version y. Do such people simply bundle Python with their applications (I've seen that approach used) or do they rely in Framework versioning support?
I bundle the python framework with applications, anyone that uses py2app will get that functionality for free when he's not using the system version of python.
That's mostly good for backwards compatibility but pretty hosed for forwards compatibility since Apple didn't really take the Framework approach to its fullest and there's really no way to say "I want - framework Foo versionX" at the link stage, compiling newer stuff against older bits (you pretty much have to go to the trouble of keeping back-rev'd copies of MacOSX around for hosting your builds). How does MacPorts help people with this, or does it?
That's not entirely true, you can explicitly link with the dylib inside the framework. That is, '-framework Python' is the same as linking with /Library/Framework/Python.framework/Versions/Current/ Python. It's not as easy as linking a framework, especially when doing this from Xcode, but it's not very hard either.
I ask because we're likely going to go with Python 2.5 for Leopard (not in the seeds yet, but soon) and there's still time to rethink that decision if it's really going to hose people.
I'm +1 on Python2.5 in Leopard. Ronald
participants (8)
-
Blair Zajac
-
Daniel J. Luke
-
Douglas Philips
-
Jordan K. Hubbard
-
Landon Fuller
-
Randall Wood
-
Ronald Oussoren
-
Weissmann Markus