GitHub post-extract shenanigans

[Aaron Madlon-Kay]

After poking around some more I think I can answer my own question:

We don't use the `extract.mkdir yes` solution because it extracts to
worksrcdir, but per the comment in the github 1.0 portgroup (linked in
previous message) the port may want to set worksrcdir to a
subdirectory of the extracted directory. So for it to be a viable
solution, we would need yet another variable like `extract.target` to
indicate where the result of extraction should be.

Maybe a flag to simply disable the github 1.0 portgroup's shenanigans
would be more appropriate.

-Aaron

On Wed, Oct 17, 2018 at 12:33 PM Aaron Madlon-Kay
<aaron+macports at madlon-kay.com> wrote:
>
> Hello all.
>
> The github 1.0 portgroup does some post-extract shenanigans to
> normalize the result of extracting the distfile: e.g. a GitHub project
> `me/myproject` will, as retrieved from GitHub, extract to
> `me-myproject-0123abc`; this is moved to `myproject` via globbing:
> https://github.com/macports/macports-ports/blob/46c352bcc820ef80909e27a57d2f5eb71569abc6/_resources/port1.0/group/github-1.0.tcl#L81
>
> ### My question
>
> I am wondering why the above is done rather than doing the following,
> which extracts directly to the desired `worksrcpath`:
>
> extract.mkdir yes
> extract.post_args-append --strip-components=1
>
> Example extract invocation (simplified):
>
> cd "/path/to/worksrcdir" && /usr/bin/gzip -dc
> '/path/to/distfile.tar.gz' | /usr/bin/tar -xf - --strip-components=1
>
> This seems to nicely solve the problem without relying on the format
> of the tarball root. Is there a reason we are not using this solution?
>
> ### Background
>
> The following confluence of issues led me to the above solution:
>
> 1. The golang portgroup has specific requirements for the worksrcdir
> related to the GOPATH (long story)
> 2. The github portgroup post-extract manipulations require that the
> worksrcdir be already present, or that the result of extraction
> matches the expected format
> 3. When `github.tarball_from` is `release` the result of extraction is
> unpredictable, so it needs to be handled by the port
> 4. The github portgroup's post-extract block can't be overridden or
> pre-empted, so additional post-extract blocks can't resolve this
> conflict
>
> The `extract.mkdir yes` solution ensures that the worksrcdir is
> correct regardless.
>
> An alternate solution might involve a flag to enable or disable the
> github portgroup's post-extract manipulations, or a new variable to
> specify the expected result of extraction independently of worksrcdir.
> But these seem inelegant if the `extract.mkdir yes` solution is
> viable.
>
> Thanks,
> Aaron