Port commit questions regarding python versions and philosophy for splitting ports

[Bradley Giesbrecht]

On Oct 29, 2010, at 5:50 AM, Michelle Gill wrote:

> Hi Daniel,
>
> Thank you so much for the reply.
>
> On Oct 28, 2010, at 10:41 AM, Daniel J. Luke wrote:
>
>> On Oct 28, 2010, at 9:17 AM, Michelle Gill wrote:
>>>
>>> * When building python packages (or any package where there are  
>>> multiple versions maintained), does one have to build to support  
>>> all versions? I only have python 2.6 on my system right now. Would  
>>> I need to install python 2.5 (and 2.7, etc.) so I can build a port  
>>> for multiple versions of python? Is support for other python  
>>> versions handled in a way that doesn't involve the submission of  
>>> packages for each python version?
>>
>> You don't have to build Portfiles for each version in the sense  
>> that you're volunteering and so whatever you want to to do help out  
>> is welcome.
>>
>> If you want to support multiple python versions, though, you will  
>> need to create Portfiles for each version.
>>
>> Fortunately, you can have multiple versions of macports python  
>> installed at once and most python packages are pretty easy to set  
>> up portfiles for.
>
> I should add that I'm not opposed to building for multiple python  
> versions. I would like to make sure I'm
> doing everything correctly with my current set up before installing  
> additional python versions, though.
>
> There have also been a few discussions about issues with atlas/numpy/ 
> etc. on the list lately. All of these
> ports are requirements for the package I intend to build. Who knows  
> if I'll run into compilation issues
> when I try to install other python versions.
>
>>
>>> * What is the philosophy regarding the incorporation of small  
>>> accessory packages (say as variants) into an existing packge vs  
>>> creating a separate build? I have built the DerApproximator  
>>> accessory package for py26-openopt and am unsure if it should be  
>>> consolidated with the existing OpenOpt package or if I should  
>>> submit a new package. My sense is that variants are for compile  
>>> time flags and that I should submit DerApproximator as a separate  
>>> package.
>>
>> As a maintainer, it's up to you to determine what method is more  
>> appropriate.
>>
>> Things to keep in mind are:
>>
>> - If it's a variant, you can only choose to install/uninstall it  
>> when installing the big package (if you install the port without  
>> the variant, and decide you want it - you have to build the port  
>> again).
>> - If it's a variant, other ports can't list it as a dependency.
>>
>> The tradeoff is that it's often slightly easier to implement as a  
>> variant, and if it's distributed in the same tarball from upstream,  
>> you only have to update one portfile if it's a variant.
>>
>
> This is very helpful--I was looking for a list of pros and cons for  
> either option. I don't recall if there is
> an actual maintainer for OpenOpt, but if there is, I'll contact him/ 
> her to discuss as well.
>
> I guess all this is assuming I am given commit access. I'm not sure  
> how long it takes them to approve
> requests.

You can always contribute new ports and patches using MacPorts Trac :)

http://trac.macports.org/newticket


Regards,

Bradley Giesbrecht