[145141] trunk/dports/python

Ryan Schmidt ryandesign at macports.org
Wed Jan 27 14:38:41 PST 2016


> On Jan 27, 2016, at 4:24 AM, Andrew Fernandes <adfernandes at macports.org> wrote:
> 
> MacPorts interprets the license field as a space-separated list of valid license names.
> 
> Ah, I vaguely remember that. I had simply copied the license field from the original Portfile in #42693.
> 
> But that didn’t cause the issue - I checked.
>> +    python.versions     27 33 34 35
>> 
> 
> Doesn't the python.versions line have to be outside this block?
> 
> Yes, that’s what I’ve done before and that’s what all the other python ports do.

Setting python.versions is what causes the python 1.0 portgroup to create the subports. If it's inside an "if {${name} ne ${subport}}" block, it can never get executed, and the subports can never get created, because at the time the if statement is evaluated no subports exist yet, so at that point ${name} will always eq ${subport}.


> However, if the line is outside the block - like every other port - I get a “port lint” error that “py27-pypyinstaller is an unmet dependency” which I simply don’t understand.

I think that's to be expected, for a port that hasn't been added to the portindex yet. You can either add it to the portindex (by running the portindex command in the dports directory as the correct user), or just ignore it and check it again later after it's been committed.


> Linting with a subport specified gives me no error.
> 
> The only way I could get rid of it - and I spent a lot of time trying and a lot of time googling, and a lot of time looking at other ports - was to move the python.versions block inside the subport-check block.





More information about the macports-dev mailing list