[Container-tools] Dev assistant implementation of nulecule spec

[Aaron Weitekamp]

Tomas, see PR: https://github.com/projectatomic/nulecule/pull/27

If this doesn't address your use case requirements make a note in the PR.

-Aaron

----- Original Message -----
> Hi,
> 
> On 23/04/15 15:57, Langdon White wrote:
> >
> >
> > On 04/23/2015 09:37 AM, Aaron Weitekamp wrote:
> >> There has been some discussion on how DevAssistant[1] might implement
> >> the nulecule spec[2]. There are a few requirements that need to be
> >> sorted out:
> 
> Just for absolute clarity, I formulated these requirements.
> 
> >> - a piece of data signifying that the app was created with DA/has some
> >> DA scripts that can be used with it
> >
> > On the first part, I am not sure I agree, unless the 2nd part is true.
> > Like, I don't think you need to indicate it was gen'd with DA (unless we
> > want to for "marketing reasons"). However, I think you need a way to
> > show the DA functionality that is available (if there is any)
> 
> Both parts are meant to signify the same, i. e. if you run DevAssistant
> (DA) in the project directory, it knows it can load these files (custom
> scripts for this app etc.). The first variant assumes a fixed directory
> structure, but I guess having links there is a bit more future-proof.
> 
> There's a different but related problem of telling devassistant what
> generic actions (as opposed to custom ones, see above) are available.
> Such actions may be: Generate documentation from Makefile, link a
> container to the current app etc. How this will be done isn't entirely
> clear at this moment, but as long as arbitrary values are allowed, it
> doesn't pose a problem. Generally speaking, we would like to infer as
> much as possible from other parts of the Atomicfile (providers for
> deployment options, requirements for setting up the project).
> 
> >> - additional metadata like Authors, Website, Issue Tracker, Summary (a
> >> shorter version of the description) etc.
> 
> I believe these are useful outside DA too, and could be general optional
> metadata fields.
> 
> >> It's not clear to me if we specifically call out the support of
> >> arbitrary data in the 'metadata' object[3] but I think we intend to.
> >> Could the devassistant data go in here?
> 
> Quite possibly.
> 
> >> Could devassistant reference
> >> remote and local files via uri://<path> in this section using their
> >> own arbitrary convention? For example,
> >> file://devassistant/somefile.json or http://path/to/remote/file.json
> 
> It could. The idea is that it could look something like this:
> 
> metadata:
>    name: My App
>    ...
>    devassistant:
>      assistants:
> 	- file://devassistant/assistants/add_custom_module.yaml
> 	- file://devassistant/assistants/serialize.yaml
>      actions: [sphinx_doc, containers, ...]
> 
> DISCLAIMER: This is nowhere near the real deal, just a general idea.
> 
> > I definitely think a core part of the spec is the ability to carry
> > arbitrary metadata to "future proof" it. I think we wouldn't even be
> > considering a new spec if kube allowed for arbitrary metadata that the
> > interpreters weren't aware of. So, +1.
> 
> +1. I say arbitrary metadata is a must. Without it, I can't imagine
> adoption outside current (arguably narrow) use cases.
> 
> > I also think the "arbitrary uri" is the part of the "arbitrary metadata"
> > that should be spec'd .. so that even if there is a new thing, it is at
> > least structured similarly
> >
> >> [1] http://devassistant.org/
> >> [2] https://github.com/projectatomic/nulecule
> >> [3]
> >> https://github.com/projectatomic/nulecule/tree/master/spec/0.0.1-alpha#metadataObject
> >>
> 
> Tomas Radej a.k.a. Sheldon
> 
> >> _______________________________________________
> >> Container-tools mailing list
> >> Container-tools at redhat.com
> >> https://www.redhat.com/mailman/listinfo/container-tools
> >
>