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
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
