Re: [gentoo-portage-dev] Re: equery refactorization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Douglas Anderson wrote: | On Thu, Dec 4, 2008 at 2:43 PM, Alec Warner [EMAIL PROTECTED] 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
-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
On Sun, Dec 7, 2008 at 12:02 PM, Michael A. Smith [EMAIL PROTECTED] 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
-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 [EMAIL PROTECTED] 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
On Sun, Dec 7, 2008 at 12:34 PM, Michael A. Smith [EMAIL PROTECTED] 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
On Sun, 7 Dec 2008 12:44:25 +0900 Douglas Anderson [EMAIL PROTECTED] 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
On Thu, Dec 4, 2008 at 2:43 PM, Alec Warner [EMAIL PROTECTED] 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
Re: [gentoo-portage-dev] Re: equery refactorization
On Wed, Dec 3, 2008 at 1:03 AM, Douglas Anderson [EMAIL PROTECTED] wrote: On Wed, Dec 3, 2008 at 7:21 AM, Michael Smith [EMAIL PROTECTED] 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
