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

[Vaclav Pavlin]

On 22 Nov 2015 17:21, "Brian (bex) Exelbierd" <bex at pobox.com> wrote:
>
>
>> 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
> wrote:
>>>
>>>
>>> > On Nov 13, 2015, at 7:19 PM, Charlie Drage <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 :)
>

Not funny:-P There is too much truth in it;)
>>
>>>
>>> 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.

Yes, it is definitely one of the solutions - and still better one than we
have right now. Anyway, I am still more in favour of having Atomic App as a
submodule of Atomic CLI as it would make it first class citizen on Atomic
Host (and anywhere where user installs Atomic CLI).

It brings challenges like version conflicts (installed tool vs. pulled
Nulecule) but as we already know, this sometimes becomes a problem even
when the tool is part of the image.

I'd suggest to stick with the merging strategy and if that fails, let's
fall back to crafting some new label craziness:)

Vasek
>
> 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
>>> 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/80de223b/attachment.htm>