github portgroup design

[Ryan Schmidt]

On Jun 22, 2015, at 4:42 PM, Lawrence Velázquez wrote:

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

Well sure, each portgroup has different needs. As long as the arguments are documented, which they are for the github portgroup, that's at least something.


>> 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.

Yes, but then we get into the problem of order of inclusion. If the github portgroup sets default master_sites, and the python portgroup sets default master_sites, which one gets used depends on the order you include the portgroups, which isn't great.

The github 1.0 portgroup does indeed set master_sites on inclusion, though the value it sets it to can vary if you change the value of github.tarball_from.

I was thinking it might be nice if the new github portgroup would define some URLs, and instead of setting github.tarball_from to some value, you would instead set master_sites to one of those URLs. For example, "master_sites ${github.releases}" or "master_sites ${github.archives}".

Or, we could use a master_sites alias, like base already does for sourceforge downloads. Not sure if we would have a single "github" alias, or multiple aliases like "github.releases" and github.archives".

Currently with the github portgroup, in the ideal case, you call github.setup and it sets everything up for you. I like that. I want to avoid the maintainer having to specify lots of different things (homepage, master_sites, livecheck, ...) to get the basic behavior. But I recognize lots of ports already have to override the defaults, either to cooperate with python or other portgroups, or even to set an alternate homepage.

Github offers its "pages" service, where you get one web site per github author, with subpages for each project. Where currently these have to be written into the port manually, I thought that might become "homepage ${github.author.page}" or "homepage ${github.project.page}".


>> 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.

I planned to make the default for github.project be ${name} and the default for github.version be ${version} (since currently we do the reverse of that).