summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorkanzure <kanzure@gmail.com>2011-01-07 18:27:09 -0600
committerkanzure <kanzure@gmail.com>2011-01-07 18:27:09 -0600
commit6e1c19fc0089069cc632e5e4275b4c1d2ed7b47a (patch)
treecf221f131a7fac62c4dc122c31d414218eb5714e
parenta7d69cdbe9257ea0b7573b27cfc9bb435f4b800e (diff)
downloadskdb-6e1c19fc0089069cc632e5e4275b4c1d2ed7b47a.tar.gz
skdb-6e1c19fc0089069cc632e5e4275b4c1d2ed7b47a.zip
converted package_spec.yaml to consistently use 80 character lines
-rw-r--r--doc/package_spec.yaml45
1 files changed, 24 insertions, 21 deletions
diff --git a/doc/package_spec.yaml b/doc/package_spec.yaml
index 3c59bf5..d9a1f9d 100644
--- a/doc/package_spec.yaml
+++ b/doc/package_spec.yaml
@@ -93,17 +93,17 @@ data format:
- when in doubt, use the same formatting style as the rest of the file.
- - data in yaml files is intended to be loaded directly into objects in one
- step, with data descriptor tags causing the resulting object to be
+ - data in yaml files is intended to be loaded directly into objects in
+ one step, with data descriptor tags causing the resulting object to be
cast as one type or another. ideally there will be no post-processing
- required after loading the yaml file, given that all of the data
- types are defined in the context used to load the yaml file,
- which is normally python. data types may (and should) be defined in
- external source code files. however, one goal is to be able to
- process metadata files without downloading the complete contents of
- each package, so tags which are defined by code in that package
- should include a tab description section at the beginning of the
- metadata file which looks like '
+ required after loading the yaml file, given that all of the data types
+ are defined in the context used to load the yaml file,which is
+ normally python. data types may (and should) be defined in external
+ source code files. however, one goal is to be able to process metadata
+ files without downloading the complete contents of each package, so
+ tags which are defined by code in that package should include a tab
+ description section at the beginning of the metadata file which looks
+ like '
!!python/object:skdb.tag_hack
tags:
- "!your_data_type"
@@ -118,10 +118,10 @@ metadata:
- package data begins with the "!package" tag and has the following
fields
- maintainer: package maintainer name and contact info.
- - license: package license. this license applies to all files in the package not
- otherwise labeled. if particular files in the package have a
- different license, it should be noted in the files section.
- - licenses shall be a string consisting of one of the following:
+ - license: package license. this license applies to all files in the
+ package not otherwise labeled. if particular files in the package have
+ a different license, it should be noted in the files section.
+ - licenses shall be a string consisting of one of the following:
- a creative commons short license name ("CC-BY-SA-3.0") from the
list of choices at http://creativecommons.org/licenses/ i
strongly encourage you not to use any of the "non-commercial"
@@ -144,13 +144,16 @@ metadata:
number must be incremented.
- description: a short (one or two paragraph) description of the
project.
- - classes: lists of data types the package makes use of, as a mapping with
- the key corresponding to the name of the package which defines those data types.
+ - classes: lists of data types the package makes use of, as a mapping
+ with the key corresponding to the name of the package which defines
+ those data types.
' threads:
- Thread'
- in this case we need the package 'threads' to define the 'Thread' data type.
+ in this case we need the package 'threads' to define the 'Thread' data
+ type.
- dependencies:
- - software: a list of other packages this package needs in order to function
+ - software: a list of other packages this package needs in order to
+ function.
- files: a list of files in the package
optional:
@@ -159,9 +162,9 @@ metadata:
current time after modifying any of the package contents. this is
best accomplished with post-commit hooks.
- dependencies:
- - build: a tree of possible sets of processes and packages used in the
- manufacturing of the artifact, not including the manufacture of
- any components which are included from other packages. for a
+ - build: a tree of possible sets of processes and packages used in
+ the manufacturing of the artifact, not including the manufacture
+ of any components which are included from other packages. for a
complex end product made from off the sheft components, this will
be mostly assembly processes like press fit or fastening. the
format of this will likely change.