Hello all,

As I suggested earlier, I'm attaching an example implementation
of github-snapshot.eclass.

All the eclass does is providing a default src_unpack() unpacking
the github snapshot into ${S}. Right now it simply does call default
src_unpack() and then does a fuzzy `mv' but that can change
in the future.

The eclass doesn't modify S or SRC_URI itself. An ebuild using it
should look like the following:

#v+
EAPI=4

inherit github-snapshot

DESCRIPTION="Random github package"
HOMEPAGE="https://github.com/foo/bar"
SRC_URI="http://github.com/foo/${PN}/tarball/${P} -> ${P}.tar.gz"

# [...]
#v-

--
Best regards,
Michał Górny

Hi,

If you use this eclass, how should your ebuild specify the commit you
want to take the snapshot from? Your example doesn't show how to do
that.

William

On Tue, 31 May 2011 13:41:03 -0500
William Hubbs <williamh@gentoo.org> wrote:

> If you use this eclass, how should your ebuild specify the commit you
> want to take the snapshot from? Your example doesn't show how to do
> that.

It's specified in SRC_URI, like usual.

--
Best regards,
Michał Górny

Il giorno mar, 31/05/2011 alle 16.24 +0200, Michał Górny ha scritto:
>
> The eclass doesn't modify S or SRC_URI itself. An ebuild using it
> should look like the following:

I have some doubts about using the unbound mv there tbh.

What happens if I need GitHub snapshots from two separate projects? It
would probably be better to provide a function to translate a mask into
a single directory and provide a default src_unpack following that.

--
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

On Tue, May 31, 2011 at 10:24 AM, Michał Górny <mgorny@gentoo.org> wrote:
> Hello all,
>
> As I suggested earlier, I'm attaching an example implementation
> of github-snapshot.eclass.
>

case ${EAPI:-0} in
0|1) die "EAPI ${EAPI} unsupported.";;
2|3|4) ;;
*) die "github-snapshot.eclass API in EAPI ${EAPI} not yet established."
esac

Why are EAPI 0 and 1 unsupported? I don't see anything that would need
EAPI 2 features.

On Tue, 31 May 2011 15:07:17 -0400
Mike Gilbert <floppymaster@gmail.com> wrote:

> case ${EAPI:-0} in
> 0|1) die "EAPI ${EAPI} unsupported.";;
> 2|3|4) ;;
> *) die "github-snapshot.eclass API in EAPI ${EAPI} not yet
> established." esac
>
> Why are EAPI 0 and 1 unsupported? I don't see anything that would need
> EAPI 2 features.

I don't see a reason to support them. They don't provide src_prepare()
which increases amount of code required by user to handle them.
Moreover, github snapshots require EAPI2 arrows in SRC_URI anyway.

--
Best regards,
Michał Górny

On Tue, May 31, 2011 at 04:24:23PM +0200, Michał Górny wrote:
> EAPI=4
>
> inherit github-snapshot
>
> DESCRIPTION="Random github package"
> HOMEPAGE="https://github.com/foo/bar"

bar is actually ${PN}.

> SRC_URI="http://github.com/foo/${PN}/tarball/${P} -> ${P}.tar.gz"

The first ${P} above isn't right, because that is where the tag of the
snapshot goes.

Regards,

William

On Tue, 31 May 2011 14:28:00 -0500
William Hubbs <williamh@gentoo.org> wrote:

> On Tue, May 31, 2011 at 04:24:23PM +0200, Michał Górny wrote:
> > EAPI=4
> >
> > inherit github-snapshot
> >
> > DESCRIPTION="Random github package"
> > HOMEPAGE="https://github.com/foo/bar"
>
> bar is actually ${PN}.

AFAIK it is a bad practice to use any variables in HOMEPAGE. Reason
unknown, vim highlights this in red.

> > SRC_URI="http://github.com/foo/${PN}/tarball/${P} -> ${P}.tar.gz"
>
> The first ${P} above isn't right, because that is where the tag of the
> snapshot goes.

This is a slightly modified copy-paste from an ebuild. In this
particular example, the tag was same as ${P}.

It is just an example. It's supposed to shortly show what needs to be
changed and what needs not. My main intent is not to suggest creating
additional variables like GITHUB_TAG and so on.

--
Best regards,
Michał Górny

On Tue, May 31, 2011 at 04:24:23PM +0200, Michał Górny wrote:
> Hello all,
>
> As I suggested earlier, I'm attaching an example implementation
> of github-snapshot.eclass.
>
> All the eclass does is providing a default src_unpack() unpacking
> the github snapshot into ${S}. Right now it simply does call default
> src_unpack() and then does a fuzzy `mv' but that can change
> in the future.
>
> The eclass doesn't modify S or SRC_URI itself. An ebuild using it
> should look like the following:

A function to generate a github url for SRC_URI is likely warranted;
should they ever grow mirrors/change their scheme, we can change it
in one spot.

Plus it makes it easier for ebuild devs to specify the url

~brian

On Tue, 31 May 2011 13:40:42 -0700
Brian Harring <ferringb@gmail.com> wrote:

> A function to generate a github url for SRC_URI is likely warranted;
> should they ever grow mirrors/change their scheme, we can change it
> in one spot.
>
> Plus it makes it easier for ebuild devs to specify the url

I thought about simply pushing mirror://github-snapshot/ instead to
handle future possibilities.

--
Best regards,
Michał Górny