> On Nov 22, 2015, at 5:13 PM, Vaclav Pavlin <vpav...@redhat.com> wrote: > > > > On Sun, Nov 22, 2015 at 5:09 PM, Brian (bex) Exelbierd <b...@pobox.com > <mailto:b...@pobox.com>> wrote: > > > On Nov 13, 2015, at 7:19 PM, Charlie Drage <cdr...@redhat.com > > <mailto:cdr...@redhat.com>> wrote: > > > > Personally I'm on the fence on whether or not we should have two > > different CLI's, however, as Dan Walsh pointed out. It's confusing > > having two similarly named CLIs. > > > > However... we should still keep the projects separate and rather > > "bridge" the two together by passing / using the atomicapp container. > > This coincides to Dusty's slides about how we could possibly add: > > 'atomic exe --label=unpack <image> COMMANDS' through a PR to atomic. > > > > Currently we have to pass in --opt3 variables in order for params such > > as '--provider=docker' and '--answers=/tmp/answers' to be used correctly. > > We > > could fix this atomicapp side by adding non-ordered arguments > > so they may be passed anywhere in the command line. > > > Could the Atomic CLI make this easier by changing the way it parses arguments > and manages labels? > > Warning, immature ideas follow. > > 1) `atomic XXX ...` just looks for a label called XXX and runs it. That way > arbitrary verbs are possible, when needed. Standards and linters should help > keep things clean. > > We thought about this before. It is definitely possible, but only adds > complexity imo
Complexity and indirection is what we specialize in :) > > 2) Could argument parsing in Atomic CLI be made more flexible than the > current OPT system? Could the parser learn how to manage arguments like this: > > RUN: docker run -it $foo $bar:o container command $destination $* > > This is an attempt to specify the following substitutions: > > $foo = whatever the entirety of a --foo== or -foo= or -foo or --foo - required > $bar = the same as $foo for s/foo/bar/ but optional > $destination = same as $foo above with s/foo/destination/ > $* anything left over > > This fixes positional problems, add some error output, etc. > > This is going to happen anyway - whole `os.environ` is going to be passed to > a RUN, INSTALL... label but it, again, adds complexity as an user has to > first figure out (from Dockerfile? From inspect?) which variables he needs to > override. True, but that is where `atomic help xxx` and docs can play a role. Zero config from day 0 is probably not real without interactivity. regards, bex > > Both are viable solutions, but imo removing one layer of indirection is good > idea:) > > Cheers, > VaĊĦek > > regards, > > bex > > _______________________________________________ > Container-tools mailing list > container-to...@redhat.com <mailto:container-to...@redhat.com> > https://www.redhat.com/mailman/listinfo/container-tools > <https://www.redhat.com/mailman/listinfo/container-tools> > > > > -- > Architect - Senior Software Engineer > Developer Experience > Brno, Czech Republic > Phone: +420 739 666 824
