[89670] trunk/dports/_resources/port1.0/group/github-1.0.tcl

[Ryan Schmidt]

On Feb 6, 2012, at 14:28, Andrea D'Amore wrote:
> On Mon, Feb 6, 2012 at 19:46, Ryan Schmidt wrote:
>> I do want to find a way to support "downloads" in addition to "tags", however this change breaks github portgroup ports that do not set a tag_prefix, and not setting tag_prefix is the most common way to use the github portgroup, so this change breaks most github portgroup ports. Take for example coffee-script. Its github.setup line is:
> 
> But assuming that a tag is the same of a version isn't correct,
> although it's a common habit.
> Just adding the v when necessary, like I see many portfiles do, isn't
> correct either. what if I need to download foo-1.2 from a tag named
> "bar"?

What software does that? I have never encountered that situation. In my experience so far the github tag name is always the version number, in some cases with a prefix like "v", therefore that is how I modeled the portgroup. If I'm right that what you've described is extremely uncommon, then I don't think the portgroup needs to accommodate it; instead, individual portfiles can override the portgroup's defaults as needed.

> Github is offering two kind of package download, and IMHO the github
> portgroup should support both.

As I said above, I don't object to that, but modifications or enhancements to the portgroup should not break existing ports.

> What I can suggest now is to add a flag to explicitly set the kind of
> github tarball download, for example github.tarball_type or
> github.tarball_from with values "tags" and "downloads".
> Setting the default value to tags would make current port work and
> leave the ability to choose to port authors.
> 
> Does this sound more reasonable to you?

Yes, I considered that method too, and it's probably fine. I had not come to a final decision on what the variable name should be. I wouldn't necessarily use the word "tarball" in the variable name; if anything, I'd use the word "distfile" instead.

Possibly, the most MacPorts thing to do would be to have a tbool called github.use_downloads, defaulting to "no".

The other method I considered was defining a github.alt_master_sites variable, and just letting the port set master_sites to ${github.alt_master_sites}. But that might be too verbose.

I'm not sure what other values should change when the author indicates the desire to use downloads: what about distname? what about livecheck? I had not yet surveyed enough github ports that use downloads to discover if there was any usual patterns we could follow, or whether each portfile will have to define these on its own.