[gentoo-dev] [discussion] GitHub eclass

[gentoo-dev] [discussion] GitHub eclass

[Vadim A. Misbakh-Soloviov]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hi there!

Since we have tons of ebuild (including -9999) for software, that uses
GitHub for sourcecode hosting —  I've got an idea to write something
like GitHub eclass, which will ease creating of such ebuilds (by
providing "sugar" functions) and, (main goal for me) by adding
possibility to switch between forks (by redefining variables on emerge
run). For example (theoretical usecase):

We have, for example, lua-socket-9999, that uses:
GH_AUTHOR=diegonehab
GH_PROJECT=lua-socket
GH_BRANCH=unstable

So, then I fork it and provide some features. And then I want to
reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do:
# GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket-9999
and it repulls sources from my fork, reemerge it and installs fine.


Any ideas/suggestions/objections/critic? Let's discuss!

--
Best regards,
mva


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-dev] [discussion] GitHub eclass

[Kent Fredric]

On 22 February 2013 19:53, Vadim A. Misbakh-Soloviov <mva@mva.name> wrote:
> Hi there!
>
> Since we have tons of ebuild (including -9999) for software, that uses
> GitHub for sourcecode hosting —  I've got an idea to write something
> like GitHub eclass, which will ease creating of such ebuilds (by
> providing "sugar" functions) and, (main goal for me) by adding
> possibility to switch between forks (by redefining variables on emerge
> run). For example (theoretical usecase):
>
> We have, for example, lua-socket-9999, that uses:
> GH_AUTHOR=diegonehab
> GH_PROJECT=lua-socket
> GH_BRANCH=unstable
>
> So, then I fork it and provide some features. And then I want to
> reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do:
> # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket-9999
> and it repulls sources from my fork, reemerge it and installs fine.

I'd make sure to add some sort of easy support to switch to
snapshotted tar.gz installs instead of live git checkouts, ie:

GH_SNAPSHOT=deadbeef  # use commit id 'deadbeef' by fetching a tar.gz
from github instead of a git clone

-- 
Kent

Re: [gentoo-dev] [discussion] GitHub eclass

[Diego Elio Pettenò]

On 22/02/2013 08:37, Kent Fredric wrote:
> I'd make sure to add some sort of easy support to switch to
> snapshotted tar.gz installs instead of live git checkouts, ie:
> 
> GH_SNAPSHOT=deadbeef  # use commit id 'deadbeef' by fetching a tar.gz
> from github instead of a git clone

This is not going to fly because a live git checkout does not need
digests in the manifest, but a tar.gz snapshot does.

I'm not against having a common way to deal with github project as they
are common, but just having a wrapper for a few variables is not worth
it IMHO.

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

Re: [gentoo-dev] [discussion] GitHub eclass

[Kent Fredric]

On 22 February 2013 20:43, Diego Elio Pettenò <flameeyes@flameeyes.eu> wrote:
> On 22/02/2013 08:37, Kent Fredric wrote:
>> I'd make sure to add some sort of easy support to switch to
>> snapshotted tar.gz installs instead of live git checkouts, ie:
>>
>> GH_SNAPSHOT=deadbeef  # use commit id 'deadbeef' by fetching a tar.gz
>> from github instead of a git clone
>
> This is not going to fly because a live git checkout does not need
> digests in the manifest, but a tar.gz snapshot does.

Though surely you could have behaviour that differs based on the right
things being specified, so that turning on GH_SNAPSHOT= becomes a
helper that generates SRC_URI , which in turn makes it so you can
satisfy the manifest digest requirement.


-- 
Kent

Re: [gentoo-dev] [discussion] GitHub eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/02/13 04:51 AM, Kent Fredric wrote:
> On 22 February 2013 20:43, Diego Elio Pettenò
> <flameeyes@flameeyes.eu> wrote:
>> On 22/02/2013 08:37, Kent Fredric wrote:
>>> I'd make sure to add some sort of easy support to switch to 
>>> snapshotted tar.gz installs instead of live git checkouts, ie:
>>> 
>>> GH_SNAPSHOT=deadbeef  # use commit id 'deadbeef' by fetching a
>>> tar.gz from github instead of a git clone
>> 
>> This is not going to fly because a live git checkout does not
>> need digests in the manifest, but a tar.gz snapshot does.
> 
> Though surely you could have behaviour that differs based on the
> right things being specified, so that turning on GH_SNAPSHOT=
> becomes a helper that generates SRC_URI , which in turn makes it so
> you can satisfy the manifest digest requirement.


SRC_URI can't be dynamic though, due to metadata cacheing.  If
GH_SNAPSHOT was always set and its value never changed, it would not
be a problem, but that would seem to contradict the point of this
variable..?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEnd3gACgkQ2ugaI38ACPCSkQD/eAbmFydGNta2HbUc2YyQYg05
ISKyLksP5PZ4BGbr9fwA/jx6M9pFGbFH2HYkx++MTTKXiLTGs6v3wxT8NjeBK6hv
=jUew
-----END PGP SIGNATURE-----

Re: [gentoo-dev] [discussion] GitHub eclass

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Fri, 22 Feb 2013 10:53:46 +0400
"Vadim A. Misbakh-Soloviov" <mva@mva.name> wrote:

> We have, for example, lua-socket-9999, that uses:
> GH_AUTHOR=diegonehab
> GH_PROJECT=lua-socket
> GH_BRANCH=unstable
> 
> So, then I fork it and provide some features. And then I want to
> reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do:
> # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket-9999
> and it repulls sources from my fork, reemerge it and installs fine.

You can also use git-2 eclass-specific variables to switch the repo.
The only difference is that you need to specify the full repo URI
rather than just the author.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] [discussion] GitHub eclass

[Rich Freeman]

On Fri, Feb 22, 2013 at 9:00 AM, Michał Górny <mgorny@gentoo.org> wrote:
>
> You can also use git-2 eclass-specific variables to switch the repo.
> The only difference is that you need to specify the full repo URI
> rather than just the author.

The full repo URI is actually copy-pastable from github, while
breaking everything up requires a few steps to configure it all.

I could see some value in being able to switch forks, but that seems
like a bit of a niche.  If you REALLY want to follow another fork
you're better off creating a new ebuild rather than just overriding
the environment variable.  You can also override the repo URI if it
uses the git eclass and again that can be copy/pasted.

As Diego/Ian pointed out, we can't really apply this well to anything
but live ebuilds.

Rich

[gentoo-dev] Re: [discussion] GitHub eclass

[Duncan]

Rich Freeman posted on Fri, 22 Feb 2013 10:09:32 -0500 as excerpted:

> On Fri, Feb 22, 2013 at 9:00 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> You can also use git-2 eclass-specific variables to switch the repo.
>> The only difference is that you need to specify the full repo URI
>> rather than just the author.
> 
> The full repo URI is actually copy-pastable from github, while breaking
> everything up requires a few steps to configure it all.
> 
> I could see some value in being able to switch forks, but that seems
> like a bit of a niche.  If you REALLY want to follow another fork you're
> better off creating a new ebuild rather than just overriding the
> environment variable.  You can also override the repo URI if it uses the
> git eclass and again that can be copy/pasted.


I I'm involved with pan upstream, I keep a slightly rewritten copy of the 
net-nntp/pan-9999 ebuild in my overlay, synced to the one in the tree.  
The main difference between it and the tree version is that my version 
has:

[[ $EGIT_PROJECT ]] || EGIT_PROJECT="${PN}2"
[[ $EGIT_REPO_URI ]] || EGIT_REPO_URI="git://git.gnome.org/
${EGIT_PROJECT}"
[[ $EGIT_BRANCH ]] || EGIT_BRANCH=master
[[ $EGIT_COMMIT ]] || EGIT_COMMIT=$EGIT_BRANCH

That allows me to keep an /etc/portage/env/net-nntp/pan file where I can 
set those as I wish, as well as keep (normally commented) vars such as 
EGIT_COMMIT, EGIT_OFFLINE, etc.

=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [discussion] GitHub eclass

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/02/13 11:19 AM, Duncan wrote:
> Rich Freeman posted on Fri, 22 Feb 2013 10:09:32 -0500 as
> excerpted:
> 
>> On Fri, Feb 22, 2013 at 9:00 AM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> 
>>> You can also use git-2 eclass-specific variables to switch the
>>> repo. The only difference is that you need to specify the full
>>> repo URI rather than just the author.
>> 
>> The full repo URI is actually copy-pastable from github, while
>> breaking everything up requires a few steps to configure it all.
>> 
>> I could see some value in being able to switch forks, but that
>> seems like a bit of a niche.  If you REALLY want to follow
>> another fork you're better off creating a new ebuild rather than
>> just overriding the environment variable.  You can also override
>> the repo URI if it uses the git eclass and again that can be
>> copy/pasted.
> 
> 
> I I'm involved with pan upstream, I keep a slightly rewritten copy
> of the net-nntp/pan-9999 ebuild in my overlay, synced to the one in
> the tree. The main difference between it and the tree version is
> that my version has:
> 
> [[ $EGIT_PROJECT ]] || EGIT_PROJECT="${PN}2" [[ $EGIT_REPO_URI ]]
> || EGIT_REPO_URI="git://git.gnome.org/ ${EGIT_PROJECT}" [[
> $EGIT_BRANCH ]] || EGIT_BRANCH=master [[ $EGIT_COMMIT ]] ||
> EGIT_COMMIT=$EGIT_BRANCH
> 
> That allows me to keep an /etc/portage/env/net-nntp/pan file where
> I can set those as I wish, as well as keep (normally commented)
> vars such as EGIT_COMMIT, EGIT_OFFLINE, etc.
> 
> =:^)
> 

git-2.eclass allows environment based overrides via ${PN}_LIVE_REPO=,
${PN}_LIVE_BRANCH=, and ${PN}_LIVE_COMMIT=

it would seem that the only thing you would need to do outside of
those is the override for EGIT_PROJECT.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEnnRgACgkQ2ugaI38ACPDiUAEAuyDkKlZL2qKCYY6wkezQ6q+k
ZtzGlqrn/MZJ2uGTipsA/RpqDpWY9AUDAZinqBwug3iJj2C46+ncBrK/tVlmpCE9
=3DD5
-----END PGP SIGNATURE-----