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

[Andrea D'Amore]

On Mon, Feb 6, 2012 at 22:24, Ryan Schmidt <ryandesign at macports.org> wrote:
> 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.

The point is that tags doesn't _have_ to be the version so we
shouldn't rely on that.
The fact that there's a v is an obvious exception, it could be a "v"
like it could be a "bzorp".

I understand you do not want to break existing portfiles but port
writers should be invited to check if a tag exists or not, taking it
from the software version is conceptually wrong, altough it fits
majority of cases.

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

The whole mechanics seems too much wrapped on most common case.

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

I see the point.

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

I'm committing a change that use tarball_from, this is a temporary fix
for the ports that currenty doesn't work.
I like the use_downloads tbool idea more, but I'll do it later.

I checked a few ports (coffee-script among these) and they are
correctly fetched.

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

Actually the distname is up to the upstream packagin. In this
"downloads" are more like a traditional hosting, letting the
repository owner to store whatever file, while a "tags" download is
automatically packaged from repository and its contents has a root
directory different than just the software, it's
"author-project-taghash", hence the rename you had to do in
post-extract.
The distname hasn't even to be in fetch request URI, the path till the
tag is enough to http-redirect to the package.

Personally I go with downloads whenever possible.

**edit:
 I read your mail about jake while typing this one, when I deleted the
version I wasn't realizing that almost all portfiles where relying on
version to complete the tag name
with the fix I'm committing, again temporary, jake works as well.



-- 
Andrea

[1] http://trac.macports.org/changeset/89692



P.S.
out of curiosity I was just parading myself because I hadn't received
any not from you on my last several commits ;-)