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