From: Douglas Anderson <dja@gendja.com>
To: gentoo-portage-dev@lists.gentoo.org
Subject: [gentoo-portage-dev] equery: RFC and code review
Date: Tue, 10 Feb 2009 19:53:57 +0900 [thread overview]
Message-ID: <efeb8d230902100253j47e85c7dr8faa9a519d9d0268@mail.gmail.com> (raw)
Hi all,
It's been a few months since we first discussed refactoring equery on
this list and I think made pretty good time and I'm reasonably happy
with it. So I'm throwing out to you all. I've tried to keep a running
list of visible changes as I went along, but I'm sure I've missed some
things. You can read that here:
http://code.google.com/p/genscripts/source/browse/equery/trunk/equery/CHANGELOG
My primary goals for the refactorization were:
* Modularize
* Clean up the UI
* Rewrite a more solid option handler
* Eliminate as much duplicated code as possible
* Clean up slop and bitrot, follow clean coding standards and style
guidelines wherever possible
* Break up large functions, write docstrings for all functions
* Get code set for Python 2.6 (tested in 2.5 and 2.6) and prepare
smooth upgrade for Py3k.
* Create a more consistent experience for the user.
This last point is surely where the most contention will stem from, so
let me argue my position. All modules except for list, check and size
display the help message when called without input (ex: equery uses).
This makes sense. It's what most other programs do. It's what emerge
does. It's what eselect does. It's the neighborly thing to do.
However these three exceptions go and start a time-consuming process
which is of very limited usefulness. With a cold cache, each process
takes at least 30 seconds. I imagine that 99 percent of people who
type 'equery list' do it by accident. And who needs to see the size of
every installed package? And checksum every installed package? Almost
useless except to a select few people who know what they're doing.
So I took the liberty of changing the default behavior of these three
modules to be more in line with the rest of equery and the world. Each
of the three displays deprecation warning explaining how to recreate
the old default behavior. I can't imagine anyone objecting outright to
this, considering there will always be more than one version of
gentoolkit in the tree (there are 6 now) so it'd be a long time before
anyone was forced into the new behavior.
That's it. For anyone interested, please read the link above and let
me know if you like it/hate it/want something else done.
For python programmers, I'd appreciate a quick code review and any
comments/criticism whatsoever (I really like criticism).
Thanks in advance,
-Doug
next reply other threads:[~2009-02-10 10:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 10:53 Douglas Anderson [this message]
2009-02-12 7:10 ` [gentoo-portage-dev] equery: RFC and code review Alec Warner
2009-02-12 8:19 ` Brian Harring
2009-02-12 10:01 ` René 'Necoro' Neumann
2009-02-12 10:39 ` Douglas Anderson
2009-02-12 10:25 ` Douglas Anderson
2009-02-12 11:27 ` Marijn Schouten (hkBst)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=efeb8d230902100253j47e85c7dr8faa9a519d9d0268@mail.gmail.com \
--to=dja@gendja.com \
--cc=gentoo-portage-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox