<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> <html><head><meta name="qrichtext" content="1" /><style type="text/css"> p, li { white-space: pre-wrap; } </style></head><body style=" font-family:'DejaVu Sans Mono'; font-size:9pt; font-weight:400; font-style:normal;"> 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@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 </body></html>