github portgroup design (was: Re: [MacPorts] #47951: tmux: moved from SF to Github)

[Lawrence Velázquez]

On Jun 4, 2015, at 7:32 PM, Ryan Schmidt <ryandesign at macports.org> 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