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 Portage Developer

 
 
LinkBack Thread Tools
 
Old 12-03-2008, 08:03 AM
"Douglas Anderson"
 
Default equery refactorization

On Wed, Dec 3, 2008 at 7:21 AM, Michael Smith <michael@smith-li.com> wrote:
> I had the same idea and even began working on a roadmap for it.
>
> Step 1: move gentoolkit to site-packages
> Step 2: move individual command classes to functionally-organized
> module-files
> Step 3: refactor and enhance docstrings to allow primary help/usage()
> function to construct from individual modules. (The goal here is to create a
> drop-in mechanism for adding new modules, so that usage() is automatically
> updated when a new module is added.)
> Step 4: Profit!
>
> Actually another approach would be to create a core __init__.py that handled
> the usage() and getopt functionality I outlined in Step 3 above, and then
> one-by-one modify the individual modules that are in the current equery so
> they could be dropped in.
>
> Thoughts?
>
> Michael
>
> On Dec 2, 2008, at 5:01 AM, Douglas Anderson wrote:
>
>> Hi, I'm interesting in tinkering with equery and doing some
>> refactorization in my spare time. I wrote a script that some people
>> mentioned would be a good module for equery (emeta, it's on bugzilla), but
>> as I was looking into that, I noticed that equery is written as a script,
>> even though it would probably really benifit from being modularized.
>>
>> Again, this is just because I have some free time right now and a
>> willingness to learn about Portage, but I thought I'd check with you guys
>> first. If I'm willing to do it without bother you all too much, would it be
>> something you're interested in me doing? My idea is to set it up more like a
>> Python package than a script, like:
>> /usr/lib/gentoolkit/pym/gentoolkit/equery/
>> /usr/lib/gentoolkit/pym/gentoolkit/equery/__init__.py
>> /usr/lib/gentoolkit/pym/gentoolkit/equery/belongs.py
>> /usr/lib/gentoolkit/pym/gentoolkit/equery/check.py
>> /usr/lib/gentoolkit/pym/gentoolkit/equery/depends.py
>> etc...
>>
>> I think it would increase startup time and make adding or upgraded modules
>> easier in the future.
>>
>> Well, I have a few more questions but I'll wait and see if this would be a
>> positive thing or not.
>>
>> Thanks for your time,
>> -Doug
>
>
>

Great, I'd like to give this a try, then.

Michael, I was personally going to go for your "other approach" of
having an __init__.py do all the setup and handle the input and send
the local opts to the individual modules. If you're interested in
working on it together, that would be great. I have a googlecodes repo
that we can work out of, or whatever (same goes for anyone else)
I'll also open up a bug for it when I have some work done.

A little RFC:
1) Spaces or tabs? Python standard is spaces, Gentoo seems to be
predominantly tabs. I personally like to use spaces when I'm writing
Python, but if that would annoy everyone later on, I'll stick to tabs.

2) Are there any other progs that depend on equery and gentoolkit that
you know of? If there are, I can try and keep an eye on things and
create as little hassle as possible.

Any other ideas?

-Doug


Wed Dec 3 11:30:01 2008
Return-path: <fedora-devel-list-bounces@redhat.com>
Envelope-to: tom@linux-archive.org
Delivery-date: Wed, 03 Dec 2008 11:04:42 +0200
Received: from hormel1.redhat.com ([209.132.177.33] helo=hormel.redhat.com)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <fedora-devel-list-bounces@redhat.com>)
id 1L7nf0-0006ZZ-Gb
for tom@linux-archive.org; Wed, 03 Dec 2008 11:04:42 +0200
Received: from listman.util.phx.redhat.com (listman.util.phx.redhat.com [10.8.4.110])
by hormel.redhat.com (Postfix) with ESMTP id D312761A42A;
Wed, 3 Dec 2008 04:04:40 -0500 (EST)
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com
[172.16.52.254])
by listman.util.phx.redhat.com (8.13.1/8.13.1) with ESMTP id
mB394bVO030723 for <fedora-devel-list@listman.util.phx.redhat.com>;
Wed, 3 Dec 2008 04:04:38 -0500
Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32])
by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB394bWb002200
for <fedora-devel-list@redhat.com>; Wed, 3 Dec 2008 04:04:37 -0500
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229])
by mx3.redhat.com (8.13.8/8.13.8) with ESMTP id mB394OFV025608
for <fedora-devel-list@redhat.com>; Wed, 3 Dec 2008 04:04:24 -0500
Received: by rv-out-0506.google.com with SMTP id f6so3759135rvb.51
for <fedora-devel-list@redhat.com>;
Wed, 03 Dec 2008 01:04:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:received:received:message-id:date:from:to
:subject:cc:in-reply-to:mime-version:content-type:references;
bh=qbAkki5p7mGGGxZ20GGO8y2K/42Ly/D5wIt9cjMabO4=;
b=dVu3Ltr4MxAO7gqEIoumy7isWNVm7F+TFBdW8YHvxxfXnip2 UaMrqFShXJvq59vWbR
N1lMtiABeZHWojsN3/q4XvfQpUeiKF8fRkgoJItB4lrJtaaI+WoqnB8CTvdY8+9BLJOX
Un9jaXk86m+weiXzDlh17wNpCHZuaZnAKmlYc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
:content-type:references;
b=KV0DSRQC3EXbkY849qpK9qdz6indYqW12tP8jpAASrxHOvM9 jJSgmcaFEmb/FTTPqi
JN+RA1FOS4tmhLvi0YRN13S7QpJoLByF6JCkRVBpWH6Zu3NKGI r0WbiM0Wijsr4GJAyK
F3Zj/VS1TJQ7cGCCsZSAoiF0PAn/NONvvGzMQ=
Received: by 10.140.133.9 with SMTP id g9mr6208802rvd.123.1228295063675;
Wed, 03 Dec 2008 01:04:23 -0800 (PST)
Received: by 10.141.195.3 with HTTP; Wed, 3 Dec 2008 01:04:23 -0800 (PST)
Message-ID: <f4586a2e0812030104y5fbd79ddlcc23b1861b2ebeb1@mail .gmail.com>
Date: Wed, 3 Dec 2008 14:34:23 +0530
From: "=?UTF-8?Q?Parag_N(=E0=A4=AA=E0=A4=B0=E0=A4=BE=E0=A5=9A)? ="
<panemade@gmail.com>
To: "Mamoru Tasaka" <mtasaka@ioa.s.u-tokyo.ac.jp>
In-Reply-To: <493649C3.8060309@ioa.s.u-tokyo.ac.jp>
MIME-Version: 1.0
References: <20081203084407.4F78C7011D@cvs1.fedora.phx.redhat. com>
<493649C3.8060309@ioa.s.u-tokyo.ac.jp>
X-RedHat-Spam-Score: 0.001
X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254
X-Scanned-By: MIMEDefang 2.63 on 172.16.48.32
X-loop: fedora-devel-list@redhat.com
Cc: fedora-devel-list@redhat.com, elfinfo-owner@fedoraproject.org
Subject: Re: rpms/elfinfo/devel elfinfo.spec,1.2,1.3
X-BeenThere: fedora-devel-list@redhat.com
X-Mailman-Version: 2.1.5
Precedence: junk
Reply-To: Development discussions related to Fedora
<fedora-devel-list@redhat.com>
List-Id: Development discussions related to Fedora
<fedora-devel-list.redhat.com>
List-Unsubscribe: <https://www.redhat.com/mailman/listinfo/fedora-devel-list>,
<mailto:fedora-devel-list-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/fedora-devel-list>
List-Post: <mailto:fedora-devel-list@redhat.com>
List-Help: <mailto:fedora-devel-list-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/fedora-devel-list>,
<mailto:fedora-devel-list-request@redhat.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1695644159=="
Sender: fedora-devel-list-bounces@redhat.com
Errors-To: fedora-devel-list-bounces@redhat.com

--===============1695644159==
Content-Type: multipart/alternative;
boundary="----=_Part_100314_19742774.1228295063677"

------=_Part_100314_19742774.1228295063677
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,
On Wed, Dec 3, 2008 at 2:26 PM, Mamoru Tasaka
<mtasaka@ioa.s.u-tokyo.ac.jp>wrote:

> Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:
>
> > Index: elfinfo.spec
> > ================================================== =================
> > RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- elfinfo.spec 3 Dec 2008 08:35:17 -0000 1.2
> > +++ elfinfo.spec 3 Dec 2008 08:43:36 -0000 1.3
> > @@ -13,7 +13,7 @@
> > This package can work without libelf.
> >
> > %prep
> > -%setup -q
> > +#%setup -q
> >
> > %build
> > make CFALGS="$RPM_OPT_FLAGS" %{?_smp_mflags}
> >
>
> This is not allowed. The correct method is to use "%setup -q -c".
>

Ahh. By mistake I removed that thing. Thanks. Fixed now.

>
> Mamoru
>

------=_Part_100314_19742774.1228295063677
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>Hi,<br><div class="gmail_quote">On Wed, Dec 3, 2008 at 2:26 PM, Mamoru Tasaka <span dir="ltr">&lt;<a href="mailto:mtasaka@ioa.s.u-tokyo.ac.jp">mtasaka@ioa.s.u-tokyo.ac.jp</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Parag Nemade wrote, at 12/03/2008 05:44 PM +9:00:<br>
<div class="Ih2E3d"><br>
&gt; Index: elfinfo.spec<br>
&gt; ================================================== =================<br>
&gt; RCS file: /cvs/pkgs/rpms/elfinfo/devel/elfinfo.spec,v<br>
&gt; retrieving revision 1.2<br>
&gt; retrieving revision 1.3<br>
&gt; diff -u -r1.2 -r1.3<br>
&gt; --- elfinfo.spec &nbsp; &nbsp; &nbsp;3 Dec 2008 08:35:17 -0000 &nbsp; &nbsp; &nbsp; 1.2<br>
&gt; +++ elfinfo.spec &nbsp; &nbsp; &nbsp;3 Dec 2008 08:43:36 -0000 &nbsp; &nbsp; &nbsp; 1.3<br>
&gt; @@ -13,7 +13,7 @@<br>
&gt; &nbsp;This package can work without libelf.<br>
&gt;<br>
&gt; &nbsp;%prep<br>
&gt; -%setup -q<br>
&gt; +#%setup -q<br>
&gt;<br>
&gt; &nbsp;%build<br>
&gt; &nbsp;make CFALGS=&quot;$RPM_OPT_FLAGS&quot; %{?_smp_mflags}<br>
&gt;<br>
<br>
</div>This is not allowed. The correct method is to use &quot;%setup -q -c&quot;.<br>
<font color="#888888"></font></blockquote><div>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>&nbsp; &nbsp; &nbsp; Ahh. By mistake I removed that thing. Thanks. Fixed now. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<font color="#888888"><br>
Mamoru<br>
</font></blockquote></div><br>

------=_Part_100314_19742774.1228295063677--


--===============1695644159==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--===============1695644159==--
 
Old 12-04-2008, 04:43 AM
"Alec Warner"
 
Default equery refactorization

On Wed, Dec 3, 2008 at 1:03 AM, Douglas Anderson <dja@gendja.com> wrote:
> On Wed, Dec 3, 2008 at 7:21 AM, Michael Smith <michael@smith-li.com> wrote:
>> I had the same idea and even began working on a roadmap for it.
>>
>> Step 1: move gentoolkit to site-packages
>> Step 2: move individual command classes to functionally-organized
>> module-files
>> Step 3: refactor and enhance docstrings to allow primary help/usage()
>> function to construct from individual modules. (The goal here is to create a
>> drop-in mechanism for adding new modules, so that usage() is automatically
>> updated when a new module is added.)
>> Step 4: Profit!
>>
>> Actually another approach would be to create a core __init__.py that handled
>> the usage() and getopt functionality I outlined in Step 3 above, and then
>> one-by-one modify the individual modules that are in the current equery so
>> they could be dropped in.
>>
>> Thoughts?
>>
>> Michael
>>
>> On Dec 2, 2008, at 5:01 AM, Douglas Anderson wrote:
>>
>>> Hi, I'm interesting in tinkering with equery and doing some
>>> refactorization in my spare time. I wrote a script that some people
>>> mentioned would be a good module for equery (emeta, it's on bugzilla), but
>>> as I was looking into that, I noticed that equery is written as a script,
>>> even though it would probably really benifit from being modularized.
>>>
>>> Again, this is just because I have some free time right now and a
>>> willingness to learn about Portage, but I thought I'd check with you guys
>>> first. If I'm willing to do it without bother you all too much, would it be
>>> something you're interested in me doing? My idea is to set it up more like a
>>> Python package than a script, like:
>>> /usr/lib/gentoolkit/pym/gentoolkit/equery/
>>> /usr/lib/gentoolkit/pym/gentoolkit/equery/__init__.py
>>> /usr/lib/gentoolkit/pym/gentoolkit/equery/belongs.py
>>> /usr/lib/gentoolkit/pym/gentoolkit/equery/check.py
>>> /usr/lib/gentoolkit/pym/gentoolkit/equery/depends.py
>>> etc...
>>>
>>> I think it would increase startup time and make adding or upgraded modules
>>> easier in the future.
>>>
>>> Well, I have a few more questions but I'll wait and see if this would be a
>>> positive thing or not.
>>>
>>> Thanks for your time,
>>> -Doug
>>
>>
>>
>
> Great, I'd like to give this a try, then.
>
> Michael, I was personally going to go for your "other approach" of
> having an __init__.py do all the setup and handle the input and send
> the local opts to the individual modules. If you're interested in
> working on it together, that would be great. I have a googlecodes repo
> that we can work out of, or whatever (same goes for anyone else)
> I'll also open up a bug for it when I have some work done.

<nitpick feel free to ignore me>
Don't put stuff in __init__.py.

Make a file called equery (no .py) and do all the work in the modules
you import; eg.

from equery import driver

if __name__ == "__main__":
driver.Run()

Then put all this code in driver.py (option parsing, signal handling,
etc...). Don't try to hide the code in __init__.py; it confuses
people who are trying to figure out what the module is for (since
__init__.py has very specific duties in declaring what is in the
module when you inspect the query module). Putting the code in a file
named 'driver.py' or similarly makes it pretty obvious (to me anyway)
what the code in that file is for (to drive a program).

Does that make sense or am I full of crap?

</nitpick>

>
> A little RFC:
> 1) Spaces or tabs? Python standard is spaces, Gentoo seems to be
> predominantly tabs. I personally like to use spaces when I'm writing
> Python, but if that would annoy everyone later on, I'll stick to tabs.

Gentoo has no official coding standards. I'd personally prefer spaces
(along with basically everything else in the Google Python Style
Guide[1]), but I'm probably not going to nitpick. It is my opinion
that tabs are used because that is what the tools were written in and
it is annoying to change from tabs to spaces

[1] http://code.google.com/p/soc/wiki/PythonStyleGuide

>
> 2) Are there any other progs that depend on equery and gentoolkit that
> you know of? If there are, I can try and keep an eye on things and
> create as little hassle as possible.
>
> Any other ideas?
>
> -Doug
>
>
 
Old 12-06-2008, 06:33 AM
"Douglas Anderson"
 
Default equery refactorization

On Thu, Dec 4, 2008 at 2:43 PM, Alec Warner <antarus@gentoo.org> wrote:
> <nitpick feel free to ignore me>
> Don't put stuff in __init__.py.
>
> Make a file called equery (no .py) and do all the work in the modules
> you import; eg.
>
> from equery import driver
>
> if __name__ == "__main__":
> driver.Run()
>
> Then put all this code in driver.py (option parsing, signal handling,
> etc...). Don't try to hide the code in __init__.py; it confuses
> people who are trying to figure out what the module is for (since
> __init__.py has very specific duties in declaring what is in the
> module when you inspect the query module). Putting the code in a file
> named 'driver.py' or similarly makes it pretty obvious (to me anyway)
> what the code in that file is for (to drive a program).
>
> Does that make sense or am I full of crap?

I see what you're saying, but using a second file, driver.py, just to
do __init__.py's job seems even more confusing. __init__.py is the
standard python constructor, and it's required to be in every module
directory, if I understand correctly. Since you have to have an
__init__.py file in the directory, which gets sourced anyway, it might
as well be used for what it's meant for, which is handling all the
initial setup of the package. If I'm misunderstanding the purpose of
__init__, please let me know.

So two best ways I can think to set it up are:
1) /usr/bin/equery only import equery from /usr/lib/gentoolkit/equery.
__init__.py in that dir runs all the setup work and handles input args
(this is quite common), and imports and runs the requested module.
This is a similar setup used by something like iotop.

or

2) /usr/bin/equery contains all the init stuff and opt handling, then
imports the separate modules as needed. This style is used by
something like pybugz, although you still have to have an __init__.py
in the module folder, it can be a lot sparser.

I was leaning toward #1 because it keeps all the code in the same directory.

>>
>> A little RFC:
>> 1) Spaces or tabs? Python standard is spaces, Gentoo seems to be
>> predominantly tabs. I personally like to use spaces when I'm writing
>> Python, but if that would annoy everyone later on, I'll stick to tabs.
>
> Gentoo has no official coding standards. I'd personally prefer spaces
> (along with basically everything else in the Google Python Style
> Guide[1]), but I'm probably not going to nitpick. It is my opinion
> that tabs are used because that is what the tools were written in and
> it is annoying to change from tabs to spaces
>
> [1] http://code.google.com/p/soc/wiki/PythonStyleGuide
>

I'm with you there, I really like that style guide as well. We should
adopt it

-Doug
 
Old 12-06-2008, 10:32 PM
"Michael A. Smith"
 
Default equery refactorization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Douglas Anderson wrote:
| On Thu, Dec 4, 2008 at 2:43 PM, Alec Warner <antarus@gentoo.org> wrote:
|> <nitpick feel free to ignore me>
|> Don't put stuff in __init__.py.
|>
|> Make a file called equery (no .py) and do all the work in the modules
|> you import; eg.
|>
|> from equery import driver
|>
|> if __name__ == "__main__":
|> driver.Run()
|>
|> Then put all this code in driver.py (option parsing, signal handling,
|> etc...). Don't try to hide the code in __init__.py; it confuses
|> people who are trying to figure out what the module is for (since
|> __init__.py has very specific duties in declaring what is in the
|> module when you inspect the query module).

It's probably a good idea that we fulfill these 'duties' in any case, but if we
sufficiently comment __init__.py I don't really see the harm.

|> Putting the code in a file
|> named 'driver.py' or similarly makes it pretty obvious (to me anyway)
|> what the code in that file is for (to drive a program).

I don't really see the point, but if it'll make a difference a symlink would be
easy enough.

|> Does that make sense or am I full of crap?

Are those two things mutually exclusive, Alec? (j/k) :P

- -Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk7C5AACgkQzwtr5yY0JZxWkACdF6+DK/C3b4k66A+ZlwQ7njHB
CsIAn3AIhNt6o6Wwbcrj7ClkOOUIbRsx
=iO5I
-----END PGP SIGNATURE-----
 
Old 12-07-2008, 02:02 AM
"Michael A. Smith"
 
Default equery refactorization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regarding gentoolkit/trunk/src/equery/tests

I discovered all the test kit that's in equery, and have been refactoring 'em.
They're written in bash, not python, so they're a candidate for some kind of
python unit testing. Right now, however, that's not a priority for me, so I'm
just making the bash cleaner and hopefully faster and more maintainable. I
think it'll be helpful as we refactor.

The question is, how maintainable are the "help" tests? These are tests that
try to confirm that the --help output of each module is correct. I think it
might be more work than it's worth to try to maintain those...

Thoughts?

- -Michael

Douglas Anderson wrote:
| Hi, I'm interesting in tinkering with equery and doing some
| refactorization in my spare time. I wrote a script that some people
| mentioned would be a good module for equery (emeta, it's on bugzilla),
| but as I was looking into that, I noticed that equery is written as a
| script, even though it would probably really benifit from being modularized.
|
| Again, this is just because I have some free time right now and a
| willingness to learn about Portage, but I thought I'd check with you
| guys first. If I'm willing to do it without bother you all too much,
| would it be something you're interested in me doing? My idea is to set
| it up more like a Python package than a script, like:
| /usr/lib/gentoolkit/pym/gentoolkit/equery/
| /usr/lib/gentoolkit/pym/gentoolkit/equery/__init__.py
| /usr/lib/gentoolkit/pym/gentoolkit/equery/belongs.py
| /usr/lib/gentoolkit/pym/gentoolkit/equery/check.py
| /usr/lib/gentoolkit/pym/gentoolkit/equery/depends.py
| etc...
|
| I think it would increase startup time and make adding or upgraded
| modules easier in the future.
|
| Well, I have a few more questions but I'll wait and see if this would be
| a positive thing or not.
|
| Thanks for your time,
| -Doug

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk7PKwACgkQzwtr5yY0JZxRfwCglG3TzY3iQR 5UzpmovYxRa6ME
YI0An13fhKAxcd0Vr7pQ8uY80SyDKLAU
=BCpZ
-----END PGP SIGNATURE-----
 
Old 12-07-2008, 02:29 AM
"Douglas Anderson"
 
Default equery refactorization

On Sun, Dec 7, 2008 at 12:02 PM, Michael A. Smith <michael@smith-li.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Regarding gentoolkit/trunk/src/equery/tests
>
> I discovered all the test kit that's in equery, and have been refactoring
> 'em.
> They're written in bash, not python, so they're a candidate for some kind of
> python unit testing. Right now, however, that's not a priority for me, so
> I'm
> just making the bash cleaner and hopefully faster and more maintainable. I
> think it'll be helpful as we refactor.
>
> The question is, how maintainable are the "help" tests? These are tests that
> try to confirm that the --help output of each module is correct. I think it
> might be more work than it's worth to try to maintain those...
>
> Thoughts?

I know some people like to write the tests and then write the code to
match, but I don't think it's a good idea for you to refactor the
tests as I'm refactoring the codebase

Especially since I'm chopping and moving things, renaming functions,
etc, as long as I think it'll help in the long term.

I even changed the format of the help output Why? Because we have
two user-oriented tools with a similar "modular" design, equery and
eselect, and yet they have a totally different naming scheme and
behave quite differently. It's unnecessarily confusing so I tried to
make them more uniform (I'll upload some code shortly). I always
though equery's --help was cluttered and confusing. A complete
overview is what `man equery' is for, IMHO.

I also changed the way equery handles input slightly. For example this
I think is unnecessarily lenient and in the end confusing, because it
goes against what most other tools do (raise an exception):

$ equery -q -i list mozilla-firefox
!!! unknown global option -i, reusing as local option

So, I don't think we should be working on the tests until we have most
of the code refactored, but I re-extend my invitation for help on that
because there's quite a bit to do!

-Doug
 
Old 12-07-2008, 02:34 AM
"Michael A. Smith"
 
Default equery refactorization

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Let me rephrase:

The tests as they are written are not all that helpful or functional. Therefore
I'm refactoring them so that they are. If I don't, they won't be any good at all.

These are not sophisticated tests that comprehensively review your code. They
simply do some sanity checks on the output of equery.

- -Michael

Douglas Anderson wrote:
| On Sun, Dec 7, 2008 at 12:02 PM, Michael A. Smith <michael@smith-li.com> wrote:
|> -----BEGIN PGP SIGNED MESSAGE-----
|> Hash: SHA1
|>
|> Regarding gentoolkit/trunk/src/equery/tests
|>
|> I discovered all the test kit that's in equery, and have been refactoring
|> 'em.
|> They're written in bash, not python, so they're a candidate for some kind of
|> python unit testing. Right now, however, that's not a priority for me, so
|> I'm
|> just making the bash cleaner and hopefully faster and more maintainable. I
|> think it'll be helpful as we refactor.
|>
|> The question is, how maintainable are the "help" tests? These are tests that
|> try to confirm that the --help output of each module is correct. I think it
|> might be more work than it's worth to try to maintain those...
|>
|> Thoughts?
|
| I know some people like to write the tests and then write the code to
| match, but I don't think it's a good idea for you to refactor the
| tests as I'm refactoring the codebase
|
| Especially since I'm chopping and moving things, renaming functions,
| etc, as long as I think it'll help in the long term.
|
| I even changed the format of the help output Why? Because we have
| two user-oriented tools with a similar "modular" design, equery and
| eselect, and yet they have a totally different naming scheme and
| behave quite differently. It's unnecessarily confusing so I tried to
| make them more uniform (I'll upload some code shortly). I always
| though equery's --help was cluttered and confusing. A complete
| overview is what `man equery' is for, IMHO.
|
| I also changed the way equery handles input slightly. For example this
| I think is unnecessarily lenient and in the end confusing, because it
| goes against what most other tools do (raise an exception):
|
| $ equery -q -i list mozilla-firefox
| !!! unknown global option -i, reusing as local option
|
| So, I don't think we should be working on the tests until we have most
| of the code refactored, but I re-extend my invitation for help on that
| because there's quite a bit to do!
|
| -Doug
|
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkk7RCgACgkQzwtr5yY0JZyPZQCgmpf9EH+D7y dzyg6RnMMHdAfj
KfsAn0jJnHshaIMLisc0XRtH9HsQZS5y
=nGdc
-----END PGP SIGNATURE-----
 
Old 12-07-2008, 02:44 AM
"Douglas Anderson"
 
Default equery refactorization

On Sun, Dec 7, 2008 at 12:34 PM, Michael A. Smith <michael@smith-li.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Let me rephrase:
>
> The tests as they are written are not all that helpful or functional.
> Therefore
> I'm refactoring them so that they are. If I don't, they won't be any good at
> all.
>
> These are not sophisticated tests that comprehensively review your code.
> They
> simply do some sanity checks on the output of equery.
>
> - -Michael

OK, I just wanted you to understand that --help and some error
messages are bound to change as I attempt to clarify them.

I also thought about renaming the "list(l)" option as "search",
because if you look at the help output, almost every module "lists"
something. equery's "list" is actually a search, I don't see why we
shouldn't name it that. I think maybe list was used because there were
already two "s" options, stats and size. Stats is not implemented so
I'm taking it out of help for now. Size can use the short "z", becaues
that's quite unique. That would free up "s" for search and it would be
a whole lot clearer.

Yes? No?

-Doug
 
Old 12-07-2008, 03:26 AM
Marius Mauch
 
Default equery refactorization

On Sun, 7 Dec 2008 12:44:25 +0900
"Douglas Anderson" <dja@gendja.com> wrote:

> I also thought about renaming the "list(l)" option as "search",
> because if you look at the help output, almost every module "lists"
> something. equery's "list" is actually a search, I don't see why we
> shouldn't name it that. I think maybe list was used because there were
> already two "s" options, stats and size. Stats is not implemented so
> I'm taking it out of help for now. Size can use the short "z", becaues
> that's quite unique. That would free up "s" for search and it would be
> a whole lot clearer.
>
> Yes? No?

No. "search" (if used at all) should be reserved for a more
comprehensive search framework (though IMO a separate tool for that is
more appropriate), not just a simple name match. "list" makes sense if
you consider that the pkgspec argument is optional, and one of the main
tasks of it is to simply list the packages in the given repository
(that's why vardb is also the default for it) without further filtering.

Also one of the main goals of equery (according to karltk, the original
author) was to have a stable user interface, compared to the deprecated
qpkg and etcat scripts. And while the equery interface isn't exactly
the best I've seen it has been stable, so you might want to think twice
before renaming options and eventually pissing off users or breaking
third-party scripts.

Marius
 
Old 12-07-2008, 03:54 AM
"Douglas Anderson"
 
Default equery refactorization

On Sun, Dec 7, 2008 at 1:26 PM, Marius Mauch <genone@gentoo.org> wrote:
> On Sun, 7 Dec 2008 12:44:25 +0900
> "Douglas Anderson" <dja@gendja.com> wrote:
>
>> I also thought about renaming the "list(l)" option as "search",
>> because if you look at the help output, almost every module "lists"
>> something. equery's "list" is actually a search, I don't see why we
>> shouldn't name it that. I think maybe list was used because there were
>> already two "s" options, stats and size. Stats is not implemented so
>> I'm taking it out of help for now. Size can use the short "z", becaues
>> that's quite unique. That would free up "s" for search and it would be
>> a whole lot clearer.
>>
>> Yes? No?
>
> No. "search" (if used at all) should be reserved for a more
> comprehensive search framework (though IMO a separate tool for that is
> more appropriate), not just a simple name match. "list" makes sense if
> you consider that the pkgspec argument is optional, and one of the main
> tasks of it is to simply list the packages in the given repository
> (that's why vardb is also the default for it) without further filtering.
>
> Also one of the main goals of equery (according to karltk, the original
> author) was to have a stable user interface, compared to the deprecated
> qpkg and etcat scripts. And while the equery interface isn't exactly
> the best I've seen it has been stable, so you might want to think twice
> before renaming options and eventually pissing off users or breaking
> third-party scripts.
>
> Marius
>
>
$ equery list -h
List all packages matching a query pattern
Syntax:
list <local-opts> pkgspec
<local-opts> is either of:
-i, --installed - search installed packages (default)
-I, --exclude-installed - do not search installed packages
-p, --portage-tree - also search in portage tree (/usr/portage)
-o, --overlay-tree - also search in overlay tree
(/usr/portage/local/layman/wschlich-testing
/usr/portage/local/layman/xwing /usr/portage/local/layman/genscripts
/usr/portage/local/layman/wschlich-testing
/usr/portage/local/layman/xwing /usr/portage/local/layman/genscripts
/usr/local/portage)
-f, --full-regex - query is a regular expression
-e, --exact-name - list only those packages that exactly match
-d, --duplicates - list only installed duplicate packages

That's an awful lot of "searching" there for something that's
definitely not a search. List is really ambiguous, but whatever.

I understand the point of having a stable interface, but this is
probably the most widely recommended tool on the forums and #gentoo.
Stability is not a good enough reason to let it bit rot. Wasn't a more
unified tool interface also one of the original goals of gentoolkit?

-Doug
 

Thread Tools




All times are GMT. The time now is 12:38 AM.

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