[gentoo-portage-dev] Re: equery refactorization

[gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Alec Warner]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

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

[gentoo-portage-dev] Python style (Was: equery refactorization)

[Michael A. Smith]

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

Actually I don't like spaces for indentation at all. A tab character and a
space character take the same number of bytes, so it takes two-to-eight times
as much space per indentation to store the same indentation as a single tab
character. On the average project that can add up to several kilobytes of
difference. Furthermore, it completely _prevents_ collaborators from enjoying a
bit of customization as to the amount of indentation. If I like my indentation
to be two spaces, and you like yours to be four, then we can each set our text
editors that way and continue to happily share code that uses tabs for indentation.

I disagree with both PEP8 and Gentoo SOC styles on the matter. I would love it
if someone could explain to me the actual benefit of using spaces over tabs.

I'll reply to the rest of the equery refactorization thread in a different email.

- -Michael

Douglas Anderson wrote:
|> [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

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

iEYEARECAAYFAkk7COYACgkQzwtr5yY0JZyGFwCcCAI1oRKkfK0W1d5U5AQBQ4D8
fooAoIQS8sH+KRdT8e9TgJ4nXOYXKgae
=71ob
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Python style (Was: equery refactorization)

[Zac Medico]

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

Michael A. Smith wrote:
> Actually I don't like spaces for indentation at all. A tab character and a
> space character take the same number of bytes, so it takes two-to-eight
> times
> as much space per indentation to store the same indentation as a single tab
> character. On the average project that can add up to several kilobytes of
> difference. Furthermore, it completely _prevents_ collaborators from
> enjoying a
> bit of customization as to the amount of indentation. If I like my
> indentation
> to be two spaces, and you like yours to be four, then we can each set
> our text
> editors that way and continue to happily share code that uses tabs for
> indentation.
> 
> I disagree with both PEP8 and Gentoo SOC styles on the matter. I would
> love it
> if someone could explain to me the actual benefit of using spaces over
> tabs.

FWIW, I feel the same way.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkk7HbgACgkQ/ejvha5XGaPBmwCfdGEMZR7iegoVmfzCicNP/omE
WV8AoORjzg8IHtbAzVvEs1QJydiPXBKF
=VoL/
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Python style (Was: equery refactorization)

[Douglas Anderson]

On Sun, Dec 7, 2008 at 9:50 AM, Zac Medico <zmedico@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael A. Smith wrote:
>> Actually I don't like spaces for indentation at all. A tab character and a
>> space character take the same number of bytes, so it takes two-to-eight
>> times
>> as much space per indentation to store the same indentation as a single tab
>> character. On the average project that can add up to several kilobytes of
>> difference. Furthermore, it completely _prevents_ collaborators from
>> enjoying a
>> bit of customization as to the amount of indentation. If I like my
>> indentation
>> to be two spaces, and you like yours to be four, then we can each set
>> our text
>> editors that way and continue to happily share code that uses tabs for
>> indentation.
>>
>> I disagree with both PEP8 and Gentoo SOC styles on the matter. I would
>> love it
>> if someone could explain to me the actual benefit of using spaces over
>> tabs.
>
> FWIW, I feel the same way.
>
> - --
> Thanks,
> Zac
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
>
> iEYEARECAAYFAkk7HbgACgkQ/ejvha5XGaPBmwCfdGEMZR7iegoVmfzCicNP/omE
> WV8AoORjzg8IHtbAzVvEs1QJydiPXBKF
> =VoL/
> -----END PGP SIGNATURE-----
>
>

Again, not starting a holy war here, I'm happy using tabs as that's
what people want, but you asked why most Python people prefer spaces,
and one of the reasons is that it's considered Pythonic to match the
indentation level of an opening parenthesis, for example:

http://rafb.net/p/SHb5sC97.html

With tabs you can't do that faithfully. And yes tabs do use less
space, but at the expense of readability. Stripping doc string out
would also use less space. As PEP 20 says, readability counts. As
Python is largely reliant on indentation for meaning in code, spaces
work well in python where they're not necessary in, say, bash. That's
just MHO.

-Doug

Re: [gentoo-portage-dev] Python style (Was: equery refactorization)

[Alec Warner]

On Sat, Dec 6, 2008 at 3:21 PM, Michael A. Smith <michael@smith-li.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Actually I don't like spaces for indentation at all. A tab character and a
> space character take the same number of bytes, so it takes two-to-eight
> times
> as much space per indentation to store the same indentation as a single tab
> character. On the average project that can add up to several kilobytes of
> difference. Furthermore, it completely _prevents_ collaborators from
> enjoying a
> bit of customization as to the amount of indentation. If I like my
> indentation
> to be two spaces, and you like yours to be four, then we can each set our
> text
> editors that way and continue to happily share code that uses tabs for
> indentation.

I would imagine most projects are not size constrained in their
sources; also most sources are zipped and it turns out a series of
spaces compresses rather well, so I don't find this to be a compelling
advantage (I have plenty of disk space, disk bandwidth, and network
bandwidth).  Perhaps when serving thousands of copies of a specific
tree this advantage will turn out to be useful in the long run (5k *
10000 req = 50meg savings.)

>
> I disagree with both PEP8 and Gentoo SOC styles on the matter. I would love
> it
> if someone could explain to me the actual benefit of using spaces over tabs.

My eyes hurt less ;)

But seriously, aside from what Douglas stated (spaces are displayed at
a constant size, and are typically smaller (on the display) than tabs
(I've never seen anyone use \t = ' ', but I guess it is possible)
there are no real benefits, it is a preference.

I'm not going to argue with you about which one is better; I agree
that tabs are nice due to tabwidth, but I still prefer spaces.

I don't think anyone on this list is nazi enough about style to reject
code based on it...I mean..you have seen portage right?  It is not the
pinnacle of style here ;)

>
> I'll reply to the rest of the equery refactorization thread in a different
> email.
>
> - -Michael
>
> Douglas Anderson wrote:
> |> [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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkk7COYACgkQzwtr5yY0JZyGFwCcCAI1oRKkfK0W1d5U5AQBQ4D8
> fooAoIQS8sH+KRdT8e9TgJ4nXOYXKgae
> =71ob
> -----END PGP SIGNATURE-----
>
>

Re: [gentoo-portage-dev] Re: equery refactorization

[Michael A. Smith]

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

[gentoo-portage-dev] Re: equery refactorization

[Michael A. Smith]

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

iEYEARECAAYFAkk7PKwACgkQzwtr5yY0JZxRfwCglG3TzY3iQR5UzpmovYxRa6ME
YI0An13fhKAxcd0Vr7pQ8uY80SyDKLAU
=BCpZ
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Michael A. Smith]

-----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+D7ydzyg6RnMMHdAfj
KfsAn0jJnHshaIMLisc0XRtH9HsQZS5y
=nGdc
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Marius Mauch]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

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

Re: [gentoo-portage-dev] Re: equery refactorization

[Michael A. Smith]

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

If we go there, we will need to transition equery from where it is to the new
stable interface through a path of functional deprecation notices. We should
have a plan.

I also think before any collaborative refactoring gets underway we need more
consensus than we have now. I think we need a formal declaration of what an
equery tool (module?) should do (abstract methods), and naming conventions for
the tools that hopefully make it hard for them to overlap too much.

- -Michael

Douglas Anderson wrote:
| 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
|
|

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

iEYEARECAAYFAkk7eEUACgkQzwtr5yY0JZyfzQCdHBJWQvgbiZUqx0p32OdE+bgU
hYQAnjLfd05eUgpVrqZEB8Jam4qyLl5z
=zSKs
-----END PGP SIGNATURE-----

Re: [gentoo-portage-dev] Re: equery refactorization

[Marius Mauch]

On Sun, 7 Dec 2008 13:54:38 +0900
"Douglas Anderson" <dja@gendja.com> wrote:

> $ 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.

So replace "search" with "list" or "look" in the help output.

> 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?

I never said that you should let it bitrot, just that changing the
syntax for IMO questionable reasons shouldn't be done lightly. I was
stictly talking about the user interface, not the API, in case that
wasn't obvious.

Marius

Re: [gentoo-portage-dev] Re: equery refactorization

[Douglas Anderson]

On Sun, Dec 7, 2008 at 9:28 PM, Marius Mauch <genone@gentoo.org> wrote:
> On Sun, 7 Dec 2008 13:54:38 +0900
> "Douglas Anderson" <dja@gendja.com> wrote:
>
>> $ 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.
>
> So replace "search" with "list" or "look" in the help output.
>
>> 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?
>
> I never said that you should let it bitrot, just that changing the
> syntax for IMO questionable reasons shouldn't be done lightly. I was
> stictly talking about the user interface, not the API, in case that
> wasn't obvious.
>
> Marius
>

Ok, I see your point and I agree with you. Thanks for the advice...
I'll work on making the backend easier to maintain and extend while
keeping the syntax as is. I still want to clean up the UI a little
bit, but I will discuss anything I'm unsure about on the list.

Thanks for bringing me back to reality :)
-Doug