Python versions, portgroups, and portfiles

[Ryan Schmidt]

On Nov 29, 2010, at 15:16, Marshall Perrin wrote:

> I've recently switched to using Python 2.7 as my primary python version, using 
> Macports to install it. I've found however that Macports' system for handling 
> python versions is a bit cumbersome, since there are separate py26-* and py27-* 
> packages, and despite the fact that 2.7 is essentially the current version of 
> Python (for all those who have not yet taken the big rewrite plunge into 3.x), 
> there just aren't that many ports for py27 yet!   (403 ports exist for py26-, 
> but only 66 for py27-). 
> 
> Now, since these are just different interpreter versions, I've found that 
> essentially every py26-* package I've needed for py27- has been trivial to 
> re-port: Just create a new portfile, update some '26's into '27's, portindex and 
> port install. Piece of cake, but sort of tedious. Over the last couple months 
> I've submitted a handful of these updated portfiles to the macports trac site. 
> So far only one has been approved and added into the repository for others to 
> use (py27-scipy).  My questions right now are:
> 
> 1) is there anything else I can do to help move along the process of getting the 
> rest of these updated? 
> 
> 2) and more specifically, if I offered to automate a mass conversion of py26- 
> portfiles into py27- versions, would the community support that effort? (and 
> would someone with commit privileges help?)   I expect the vast majority of 
> these packages could be converted to 2.7 in an automated fashion, tested that 
> they install and operate properly, and then batch committed. 
> 
> Since 2.7 is going to be a long-term stable version of python (see 
> http://docs.python.org/dev/whatsnew/2.7.html) it seems like we would want to get 
> really solid support for it into macports. This is useful for me personally, so 
> I'd like to help the community with it if possible. Let me know what you think. 

You're right, we still seem to have an unofficial bias toward Python 2.6 in MacPorts. Assuming Python 2.7 works fine, I agree it would be great to get our Python 2.7 port collection up to par with the Python 2.6 collection, and to switch ports from using 2.6 by default to using 2.7.

I'll give you some insight into my behavior as a committer. I often scan the new tickets, to see what I can do, and I tend to gravitate toward the port update tickets. These are usually simple to evaluate, test and apply. I admit I usually avoid the port submission tickets, because they are so much harder to evaluate. If it's a totally new port, there are usually at least a dozen things I have to change in the portfile. The author probably didn't test the universal variant or consider non-default build_archs or consider supported_archs or consider installing additional documentation files or know about fetch groups or portgroups or the most efficient and best way to express everything they did. Then I have to test if it actually builds, which in my experience on new ports is less likely than for updates; if it doesn't build then all my work is (for the moment) for naught as I have to go back to the submitter and figure out why it built for them but not for me. It's rather tedious.

Submitting a Python 2.7 version of a port for which a Python 2.6 version already exists is somewhere in between. It's a new port, but if done properly, differs only very slightly from the other version. But it can get tedious as well, if the submitter doesn't indicate what existing port they copied it from (the 2.6 version? 2.5? 2.4? 3.1?), and if they also simultaneously decided to reformat the entire portfile, that usually makes me give up in exasperation. So the easiest way for us to accept Python 2.7 versions of existing Python 2.6 ports is to receive a diff from the Python 2.6 portfile, and the diff should of course include the minimum changes needed to accomplish the update. (It should not include whitespace changes, or other functional changes that would be just as applicable to the original port; if you want those kinds of changes made, submit them in another ticket against the original port first and wait for that to be committed.) This way we can look at the diff, see that it is good, "svn cp" the Python 2.6 port to the Python 2.7 port, apply the diff, build it, and commit it.

I also tend to avoid or at least put off tickets containing changes for more than one port. I like being able to fix one port and then resolve the ticket. The likelihood of failure increases the more ports are included in one ticket, and I don't like accepting a ticket, working on a few of the ports in the ticket, then finding one of them doesn't work and having to wait on the rest until the submitter figures out what's wrong (or having to figure it out myself). Such tickets also tend to get forgotten, as each day brings a fresh new batch of tickets to be dealt with.