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

[petr]

I like this discussion on portgroup design very much, also because I was trying to come up with a Globus portgroup. I was quite puzzled on how it should work, and I actually started from the Github group. At the end I found myself experimenting with two version, one with setup procedure one without. 

I think it is worth documenting some of the point mention in this thread, as it is not obvious when starting to get hands on a new portgroup.

~petr



On 22 Jun 2015, at 23:42, Lawrence Velázquez <larryv at macports.org> wrote:

> 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
> _______________________________________________
> macports-dev mailing list
> macports-dev at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev