FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 05-25-2012, 03:42 PM
Mike Frysinger
 
Default comprehensive eclass checking in repoman

On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
> foo-functions.

i was thinking of extending the metadata to handle this. did you have any
specific ideas in mind ? i can see inheriting say distutils should not require
people to also inherit python eclasses ...
-mike
 
Old 05-25-2012, 04:06 PM
Alexey Shvetsov
 
Default comprehensive eclass checking in repoman

Mike Frysinger писал 2012-05-25 19:42:

On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:

Is there any sane way to handle sub-eclasses? eg. foo-base inherits
foo-functions.


i was thinking of extending the metadata to handle this. did you
have any

specific ideas in mind ? i can see inheriting say distutils should
not require
people to also inherit python eclasses ...
-mike


May we can use eclass dep graph?
--
Best Regards,
Alexey 'Alexxy' Shvetsov
Petersburg Nuclear Physics Institute, NRC Kurchatov Institute,
Gatchina, Russia

Department of Molecular and Radiation Biophysics
Gentoo Team Ru
Gentoo Linux Dev
mailto:alexxyum@gmail.com
mailto:alexxy@gentoo.org
mailto:alexxy@omrb.pnpi.spb.ru
 
Old 05-25-2012, 04:28 PM
Mike Frysinger
 
Default comprehensive eclass checking in repoman

On Friday 25 May 2012 12:06:49 Alexey Shvetsov wrote:
> Mike Frysinger писал 2012-05-25 19:42:
> > On Thursday 24 May 2012 23:47:23 Ryan Hill wrote:
> >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
> >> foo-functions.
> >
> > i was thinking of extending the metadata to handle this. did you
> > have any
> > specific ideas in mind ? i can see inheriting say distutils should
> > not require
> > people to also inherit python eclasses ...
>
> May we can use eclass dep graph?

no ... that sort of defeats the whole reason that drove this work. we don't
want the mere fact that one eclass inherits another to imply that it's part of
that eclasses guaranteed API. a lot of eclasses inherit eutils, but i don't
think any of them should be guaranteeing that inherit which means ebuilds need
to include it themselves if they use functions from it (like epatch).

there are a cases with split up or hierarchical eclasses (java, mysql, qt,
php, python, xorg come to mind) where the entry point might vary, but they all
share core eclasses that largely should not be inherited by the end ebuild.

maybe a new eclass-level keyword @INHERITED-API ? it takes a space delimited
list of eclasses that are guaranteed by the API. so in distutils.eclass, we'd
add:
# @INHERITED-API: python

and repoman would use this to build a tree of implicit funcs to allow w/out a
direct inherit.
-mike
 
Old 05-25-2012, 06:38 PM
Steven J Long
 
Default comprehensive eclass checking in repoman

Mike Frysinger wrote:
> Alexey Shvetsov wrote:
>> Mike Frysinger писал:
>> > Ryan Hill wrote:
>> >> Is there any sane way to handle sub-eclasses? eg. foo-base inherits
>> >> foo-functions.
>> >
>> > i was thinking of extending the metadata to handle this. did you
>> > have any
>> > specific ideas in mind ? i can see inheriting say distutils should
>> > not require
>> > people to also inherit python eclasses ...
>>
>> May we can use eclass dep graph?
>
> no ... that sort of defeats the whole reason that drove this work. we
> don't want the mere fact that one eclass inherits another to imply that
> it's part of
> that eclasses guaranteed API. a lot of eclasses inherit eutils, but i
> don't think any of them should be guaranteeing that inherit which means
> ebuilds need to include it themselves if they use functions from it (like
> epatch).
>
> there are a cases with split up or hierarchical eclasses (java, mysql, qt,
> php, python, xorg come to mind) where the entry point might vary, but they
> all share core eclasses that largely should not be inherited by the end
> ebuild.
>
> maybe a new eclass-level keyword @INHERITED-API ? it takes a space
> delimited
> list of eclasses that are guaranteed by the API. so in distutils.eclass,
> we'd add:
> # @INHERITED-API: python
>
> and repoman would use this to build a tree of implicit funcs to allow
> w/out a direct inherit.

++ That sounds like a clean solution to me.

> Steven J Long wrote:
>> You could maybe tighten the false-negative side by scanning all functions
>> defined in an eclass, and warning if they're undocumented.
>
> that happens now when you emerge eclass-manpages, but i suspect no one
> cares. if you run the script by hand on your eclass, it'll tell you the
> same thing.

So, if eclass-manpages /is/ installed, then it gets used to check the
documentation by repoman?

Why not just make it a required dependency, so it's "a new feature"? It may
well be that people just don't know about it, and would welcome repoman a
reminder to update eclass documentation (eg hard error if they added the
function, overrideable error if they've edited the eclass, and warning if
they are just using it, latter two of which could perhaps talk to pybugz.)

After all, it's their name on the commit.

Regards,
Steve.
--
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
 
Old 05-25-2012, 07:02 PM
Mike Frysinger
 
Default comprehensive eclass checking in repoman

On Friday 25 May 2012 14:38:34 Steven J Long wrote:
> > Steven J Long wrote:
> >> You could maybe tighten the false-negative side by scanning all
> >> functions defined in an eclass, and warning if they're undocumented.
> >
> > that happens now when you emerge eclass-manpages, but i suspect no one
> > cares. if you run the script by hand on your eclass, it'll tell you the
> > same thing.
>
> So, if eclass-manpages /is/ installed, then it gets used to check the
> documentation by repoman?

no. while generating the manpages, the script will warn you bad comment
blocks or unknown keywords.

$ cd /usr/portage
$ ./app-portage/eclass-manpages/files/eclass-to-manpage.sh
eclass/*.eclass
...
alternatives.eclass:
warning:41: alternatives.eclass: no @MAINTAINER found
...
gnuconfig.eclass:
error:103: eclass not documented yet (no @ECLASS found)
...
leechcraft.eclass:
warning:12: Unexpected tag in "funcvar" state: # @DESCRIPTION:
...
-mike
 
Old 05-26-2012, 03:13 AM
Ryan Hill
 
Default comprehensive eclass checking in repoman

> maybe a new eclass-level keyword @INHERITED-API ? it takes a space delimited
> list of eclasses that are guaranteed by the API. so in distutils.eclass, we'd
> add:
> # @INHERITED-API: python
>
> and repoman would use this to build a tree of implicit funcs to allow w/out a
> direct inherit.

Yeah that works.


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org
 

Thread Tools




All times are GMT. The time now is 07:32 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org