[Piglit] [PATCH 3/3] piglit: Add piglit command
Dylan Baker
baker.dylan.c at gmail.com
Wed Apr 30 15:40:16 PDT 2014
On Wednesday, April 30, 2014 15:21:37 Jordan Justen wrote:
> On Wed, Apr 30, 2014 at 1:58 PM, Dylan Baker <baker.dylan.c at gmail.com> wrote:
> > On Wednesday, April 30, 2014 13:42:09 Jordan Justen wrote:
> >> Anyway, piglit_cmd.py is the source that controls the piglit command,
> >> so it can evolve to present something different.
> >>
> >> This patch seems like a reasonable step which would allow you to then
> >> re-implement the unified interface as you see fit.
> >
> > It's not the interface I have a problem with, it's the implementation.
> >
> > This isn't what we want at all. There is zero code here I would want to
> > use, and it creates a situation where the user interface will change,
> > and we're left with unhappy users.
>
> So, you are fine with the interface, but it is going to have to change?
>
> And, our users (??) will be unhappy if we change the interface, but
> you want to do something similar, and they'll be okay with that
> change?
Let me rephrase. I'm good with the general idea
Let my draw the scenario I'm worried about, people (including our QA
team) beginusing this wrapper. We decide that another layer of argparse
is simpler and easier to work with. There are minor differences which
break users wrapper scripts and they become unhappy.
This is exactly what happened when I did the getopt to argparse
conversion, because there were subtle differences between the way they
worked.
I guess what I don't see is the pressing problem that this is
solving that we need to land this implementation. I've toyed with
argparse a couple of times (I just cleaned up github or I'd have a
branch to point you at doh!)
Le me be clear here, I like the idea, it's the implementation that
concerns me. Particularly because there is the potential for
differences, it seems more sensible to me to just develop what we want
now, and not worry about it later.
>
> And, you have no feedback other than throw it all out and create a
> single argparsed based thing with a similar interface?
>
> That about sum it up? :)
>
> In terms of interface changes, I think 'piglit-run.py [args]' to
> 'piglit run [args]' is a fairly small adjustment.
>
> I've really never thought piglit's command interface was particularly
> bad (or good :), which is why I'm just looking to do the minimal
> translation here. I do think it is pretty bad the way we install
> piglit binaries and libraries, so I was just trying to fix that.
I've never really thought it was good, I tend to lean toward bad.
But, changing the ABI is always tough and I've never felt it worth the
uphill battle to make the change.
>
> -Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140430/5649cc49/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20140430/5649cc49/attachment-0001.sig>
More information about the Piglit
mailing list