[Container-tools] Dev assistant implementation of nulecule spec

[Tomas Radej]

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
>