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

[Ryan Schmidt]

On Feb 6, 2012, at 16:28, Andrea D'Amore wrote:
> On Mon, Feb 6, 2012 at 22:24, Ryan Schmidt 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.

I would guess that in the vast majority of projects, when a tag is created, the tag name is or ends with the version number. This was the case in all the ports that I converted to the github portgroup so far. If you've found one that doesn't follow that convention, let me know.

> The fact that there's a v is an obvious exception, it could be a "v"
> like it could be a "bzorp".

Right, the tag prefix can vary. In my experience so far it's usually been empty or "v" but it could be anything. That is why I made the tag prefix configurable via the 4th parameter of the github.setup proc.

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

That is completely the point: a portgroup exists in order to move commonly-used code out of portfiles and into a portgroup. For the vast majority of projects that follow what appears to be the usual github practices, the portgroup works as is. For the few projects that deviate from the usual, the portfile itself can override the portgroup. If the portgroup is too much of a hassle to use in a particular case, you don't have to use it. It's there to make your life easier; if it doesn't do that, don't use it.


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

I haven't decided yet. Certainly the tarball you get from a tag is automatically created so there can be no error in its creation while downloads are manually prepared by the developer and could be erroneous. Also, in the first project I looked at that has both, PlayerPiano, for which I've been trying to create a port, the "download" is a pre-compiled binary only; to get the source code I have to go to the "tag" tarball.

https://github.com/amazingsyco/PlayerPiano