> > My initial thinking was to always generate a tarball dinamically, so that
> > you don’t have to explicitly update a job file. It would go like this:
> >
> > $ lava job submit FOO.json
> >
> >   submits FOO.json as ir
> 
> This works.
> 
> > $ lava testdef submit FOO.yaml
> >
> >   creates the tarball and a job file dinamically; submit those
> >
> > $ lava script submit FOO.sh
> >
> >   creates testdef, tarball and job file dynamically; submit them
> 
> These two are still missing.
> 
> After showing this at Connect though, the common patterns were:
> - I will not use this (mostly from QA or people that knows how to write testdef)
> - There are too many commands (from a couple of Linaro employees and
> ARM ones too, hence the "lava init" stuff that will do everything
> almost automatically).

OK, that's good to know. I think we can reduce the number of commands,
but still keep the functionality - because craeting testdefs
automatically is *not* intended at people who already know how to create
them by themselves. :-)

> >> -            user_input = raw_input(prompt).strip()
> >> +            data = raw_input(prompt).strip()
> >>          except EOFError:
> >> -            pass
> >> +            # Force to return None.
> >> +            data = None
> >>          except KeyboardInterrupt:
> >>              sys.exit(-1)
> >> -
> >> -        if user_input is not None:
> >> +        return data
> >> +
> >> +    @classmethod
> >> +    def serialize(cls, value):
> >> +        """Serializes the passed value to be friendly written to file.
> >> +
> >> +        Lists are serialized as a comma separated string of values.
> >
> > I already saw something about serializing lists above. Can we keep all this
> > list serialization/deserialization just here?
> 
> What do you mean? Having a single method to serialize and deserialize
> instead of the two we have right now?
> "serialize" and "deserialize" are in the same class (Parameter), the
> LIST_SERIALIZE_DELIMITER is a module constant.

Above there was a call to serialize, and maybe this should be handled
transparently inside this class. The factoring in serialize/deserialize
is good already.

> >> +        :param value: The value to serialize.
> >> +        :return The serialized value as string.
> >> +        """
> >> +        serialized = ""
> >> +        if isinstance(value, list):
> >> +            serialized = LIST_SERIALIZE_DELIMITER.join(
> >> +                str(x) for x in value if x)
> >> +        else:
> >> +            serialized = str(value)
> >> +        return serialized
> >
> > I wonder if we can we use a existing serialization instead of using a arbitrary
> > delimiter ...  e.g. json + base64, this way we don’t have to limit ourselves to
> > values that do not contain a comma. But OTOH we want something that is readable
> > (and editable!) in the config file ...
> 
> I wanted to use something that could have been human readable
> (avoiding also all hashing mechanism), and easily to modify.
> I considered also pickle, but then I would have preferred to pass
> everything through it rather than just a small set of values.
> We can probably use just json.dumps() and json.loads(), even if I'm
> not so sure about that... why not using just json or YAML in the
> config that have better marshaling support?

Agreed. We only have to consider whether we expect people to edit that
file manually or not, because the serialization of the entire file in
either JSON or YAML might mess up with the order in which a user would
write the configuration.

But maybe in the end what we are calling configuration is actually just
a cache of pre-answered questions instead of an actual configuration
file ...

Does that make sense?