Re: [MirageOS-devel] build workflow

[Richard Mortier <richard.mortier@xxxxxxxxxxxx>]

On 30 November 2016 at 18:43, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:
> cc'ed mirageos-devel again
>
> On 30/11/2016 18:37, Sean Grove wrote:
>> Thanks so much for going over this with a fine-toothed comb, I love the
>> idea of the whole process being smoother.
>
>
> And your feedback is greatly appreciated since you're working with it :)
>
>
>>> - mirage describe should work with and without a configured unikernel
>>> (--eval vs --no-eval)
>>
>> I'm coming at this from an inexperienced outsider's perspective, so feel
>> free to ignore my comments, but I'm a bit concerned about overloading each
>> command to have two modes that may not be obvious why it's behaving one way
>> rather than the other. For giving support to other people, it's quite nice
>> to be able to say, "run this - it'll throw an error if you've done it
>> wrong, and then tell you to run an alternative command".
>
> agreed.  mirage describe is around now with those two modes, I agree we
> should just drop the non-eval part and error to run mirage configure
> (and mirage configure without arguments should IMHO default to -t unix
> as it is now).

At this point, I disagree with both of those.

In general it seems to me that we've been trying to move to a model
where we are more rather than less explicit about configurations;
having a default `-t` value seems a retrograde step. (I'd actually
prefer to see mirage get more demanding about specifying things,
possibly with constraints among options able to be expressed -- eg.,
if you specify IP address, then you can't specify DHCP but you must
specify netmask --  but that may require extra Functoria support.)

Dropping the non-eval part of describe means removing a useful feature
of `mirage describe --dot` IMO, where all the possible dependencies
can be displayed. Why do that?

> mirage describe without --eval looks to me very similar to mirage help,

I'm now wondering: what was the rationale for having `mirage describe`
vs `mirage help` at all?
Maybe it would be better to incorporate the tty-output options of
`describe` into the `help` output, and have `mirage describe` only
produce the `--dot` output using the cached result of `mirage
configure` if available, or not if not?

-- 
Richard Mortier
richard.mortier@xxxxxxxxxxxx

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel