Port commit questions regarding python versions and philosophy for splitting ports
brad at pixilla.com
Fri Oct 29 07:03:34 PDT 2010
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
>> As a maintainer, it's up to you to determine what method is more
>> 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
>> - 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
You can always contribute new ports and patches using MacPorts Trac :)
More information about the macports-users