[70067] trunk/dports/python

[Blair Zajac]

On 7/29/2010 9:55 PM, Ryan Schmidt wrote:
> On Jul 29, 2010, at 23:46, Joshua Root wrote:
>> On 2010-7-30 14:39 , Ryan Schmidt wrote:
>>> [...] I feel it's important that each portfile embody our best practices, so that a prospective new portfile developer can read any portfile and learn good habits. The best practice in this case is to append to the portgroup's dependencies so they don't get overwritten. In the case of these three ports, true, the dependencies being added are other python modules, so they already have the python dependency from the portgroup. But what if a new developer reads one of these three portfiles and uses it as the basis for a new python module portfile that doesn't have a dependency on another python module but does have a dependency on some other library? This person might not recognize the nuance of having to maintain the portgroup's python dependency, since in these revisions you've removed the only clue that this was the case. I recommend you go back to using -append to make this need clear.
>>
>> And I'd recommend that people understand what they're doing instead of
>> blindly copying code.
>
> Ideally, yes. :) But anything we can do to reduce our own workload is a good thing, right? And we do spend a lot of time correcting portfiles that get submitted by people who don't understand what they're doing. It's natural for someone who hasn't written a portfile before to not know what they're doing. I think you'll agree that our Guide in its present form is far from adequate in explaining the depth and nuance of portfile development possibilities, which is why we still refer interested new developers to just read some actual portfiles to see how they're written. And if we're doing that, then we should ensure the portfiles actually embody the type of portfile authoring we want them to imitate.

I'm definitely of the mind to use the suggested practice in all 
portfiles unless there's a good reason not to.

I don't have a lot of time to learn Tcl or get other things right in 
MacPorts, so if I end up looking at other ports on how that's done, that 
is the fastest way most of the time.

Blair