Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Steven J Long <slong@...>
Subject: Re: Re: comprehensive eclass checking in repoman
Date: Fri, 25 May 2012 19:38:34 +0100
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 ;-)




Replies:
Re: Re: Re: comprehensive eclass checking in repoman
-- Mike Frysinger
References:
comprehensive eclass checking in repoman
-- Mike Frysinger
Re: Re: comprehensive eclass checking in repoman
-- Mike Frysinger
Re: Re: comprehensive eclass checking in repoman
-- Alexey Shvetsov
Re: Re: comprehensive eclass checking in repoman
-- Mike Frysinger
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: Re: comprehensive eclass checking in repoman
Next by thread:
Re: Re: Re: comprehensive eclass checking in repoman
Previous by date:
Re: Re: comprehensive eclass checking in repoman
Next by date:
Re: Re: Re: comprehensive eclass checking in repoman


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.