Python 2.5 and py-crypto...

[Weissmann Markus]

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 at 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/