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