On Jun 4, 2015, at 7:32 PM, Ryan Schmidt <[email protected]> wrote:
> I agree setup procs are not the best.
I also don't like that the semantics of the arguments are not obvious. We might
know from experience what the different components of
github.setup foo bar 1.0 foo-
mean, but it doesn't lend itself to being understood. And then each portgroup
with a setup proc uses different arguments.
> But how would you implement the github portgroup differently to avoid it?
>
> I think portgroups that don't do anything by default are best, as this makes
> it easier for portgroups to be combined or enabled only in subports for
> example; there must be some command or option that triggers the portgroup to
> do its thing. For example in the python 1.0 portgroup, setting
> python.versions is the trigger, and in the php 1.1 portgroup, setting
> php.branches is.
Agreed, although I think it's fine for portgroups to set defaults for certain
metadata options, like homepage, master_sites, livecheck.type, etc., because
ports can easily override them.
Certain other behaviors are not easily undone (e.g., creating new subports,
pre/post-phase scripts, variants), so they should definitely require a trigger.
> So what would be the trigger for a hypothetical new github portgroup, if not
> github.setup? . . . After a bit of consideration, perhaps setting
> github.author would make sense.
That sounds reasonable. The portgroup would need some logic to make sure that
github.project and github.version are also set, but that's not without
precedent.
vq
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
