[Container-tools] [atomic-devel] AtomicApp/Nulecule Design and Workflow

[Brian (bex) Exelbierd]

> On Nov 22, 2015, at 5:13 PM, Vaclav Pavlin <vpavlin at redhat.com> wrote:
> 
> 
> 
> On Sun, Nov 22, 2015 at 5:09 PM, Brian (bex) Exelbierd <bex at pobox.com <mailto:bex at pobox.com>> wrote:
> 
> > On Nov 13, 2015, at 7:19 PM, Charlie Drage <cdrage at redhat.com <mailto:cdrage at 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-tools at redhat.com <mailto:Container-tools at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/container-tools/attachments/20151122/52c12b6e/attachment.htm>