{"_id":"552c27bb7820b80d00aa4ede","version":{"_id":"5476bf10817e8d080031f98b","__v":17,"project":"5476bf0f817e8d080031f988","createdAt":"2014-11-27T06:05:04.263Z","releaseDate":"2014-11-27T06:05:04.263Z","categories":["5476bf10817e8d080031f98c","5477c46cf3736008009e9eb5","5477c474f3736008009e9eb6","5477c47ef3736008009e9eb7","5477c48ff3736008009e9eb8","5477c4948deb230800808bf0","54e68328154f8e0d0007b55c","54e90194c8e0c00d007ac061","54eed2275bf74a0d00ef4076","54f7a7be0a3cbb0d00d666fb","559b0ebf7ae7f80d0096d871","55d697f9ae529e0d00d34f03","562d4dcc8c6e5a0d00d6ed1d","562e591c4376430d006f17e0","568f0e73bdb9260d00149d8c","5719542aac1e2e0e001834c6","57a14a8ed778850e0047e230"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"category":{"_id":"5477c47ef3736008009e9eb7","__v":10,"pages":["5477c4dbf3736008009e9eb9","5477c545f3736008009e9ebc","54d36f225616470d0013ccf9","54d372fa69578e0d0027311f","54d3e371514a230d0018195a","54d410f79873ad0d00b3793b","54d42ca39873ad0d00b37950","54e9099bf152c50d009b49b5","552c27bb7820b80d00aa4ede","5570b1829ea7860d008b272f"],"version":"5476bf10817e8d080031f98b","project":"5476bf0f817e8d080031f988","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2014-11-28T00:40:30.938Z","from_sync":false,"order":5,"slug":"packages","title":"Packages"},"user":"54c096f492501c0d000b38a7","__v":30,"parentDoc":null,"project":"5476bf0f817e8d080031f988","updates":["5580f17b04ae5b0d00262847","5717ccc98f02e80e00618116"],"next":{"pages":[],"description":""},"createdAt":"2015-04-13T20:31:55.536Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":true,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"The manifest file is used to provide metadata and parameters for packages uploaded to Transcriptic.  It can be thought of as a markdown language you can use to create a graphical user interface for your protocols so that they can be parameterized and launched easily through the web app.\n\nThe basic structure of a `manifest.json` file is as follows:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"format\\\": \\\"python\\\",\\n  \\\"license\\\": \\\"MIT\\\",\\n  \\\"protocols\\\": [\\n    {\\n      \\\"name\\\": \\\"sample5\\\",\\n      \\\"version\\\": \\\"1.0.0\\\",\\n      \\\"display_name\\\": \\\"Sample Protocol #5\\\", \\n\\t\\t\\t\\\"description\\\": \\\"This is a sample protocol.\\\",\\n      \\\"command_string\\\": \\\"python sample5.py\\\",\\n      \\\"inputs\\\": {},\\n      \\\"preview\\\": {\\n        \\\"refs\\\":{},\\n        \\\"parameters\\\": {}\\n\\t\\t\\t}\\n    }\\n  ]\\n}\\n\",\n      \"language\": \"json\",\n      \"name\": \"manifest.json\"\n    }\n  ]\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"info\",\n  \"body\": \"A useful tool for editing your manifest can be found at http://jsoneditoronline.com\"\n}\n[/block]\n## Many protocols in one manifest\nA manifest may contain one or multiple protocols in its `protocols` array.  The best way to organize a directory containing multiple protocols is to have the manifest file referring to all of them at the root of the directory and code for each of the protocols in separate subfolders.  The `command_string` field should call each one accordingly. \n\nFor example, if your language of choice is Python, your directory structure would look something like:\n\n```\nmy_package/\n    protocol_1/\n        __init__.py\n        protocol.py\n    protocol_2/\n        __init__.py\n        protocol.py\n   manifest.json\n```\n\nand your `manifest.json` would call each protocol as a module:\n\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"{\\n  \\\"protocols\\\": [\\n    {\\n      \\\"name\\\": \\\"protocol1\\\",\\n      \\\"version\\\": \\\"1.1.2\\\",\\n      \\\"display_name\\\": \\\"My First Protocol\\\", \\n      \\\"command_string\\\": \\\"python -m protocol_1.protocol\\\",\\n      ...\\n    },\\n    {\\n      \\\"name\\\": \\\"protocol2\\\",\\n      \\\"version\\\": \\\"2.0.5\\\",\\n      \\\"display_name\\\": \\\"My Second Protocol\\\",\\n      \\\"command_string\\\": \\\"python -m protocol_2.protocol\\\",\\n      ...\\n    }\\n  ]\\n  ...\\n}\\n\",\n      \"language\": \"json\",\n      \"name\": \"manifest.json\"\n    }\n  ]\n}\n[/block]\n## Protocol specific information\nHere we will outline the various fields within a manifest:\n\n### name\nThis is a shortname for your protocol, usually one [CamelCased](http://en.wikipedia.org/wiki/CamelCase) word.  This is the name you will use to refer to your protocol when you run `transcriptic preview` or `transcriptic analyze` from the command-line (more on that later).  This name will appear in the protocol browser on secure.transcriptic.com unless you specify another name in the `display_name` field.  \n\n### command_string\nThis is a string that represents exactly how you would run your protocol from the command-line from the directory that your manifest.json file is located in.  Keeping it simple, assuming your protocol was in the same directory as your manifest.json file and was called `sample_protocol.py`, the command string would be `python sample_protocol.py`.\n\n### parameters\nParameters specified in this stanza get passed to the protocol script specified in the \ncommand string.  Parameters must be passed in the format expected by their input type. \n\n### inputs\nAn input refers to an editable field on a protocol within the protocol browser, they will allow you to replace the parameters you hard-coded into the preview once the protocol is uploaded as a package to the web app.  There are several types of inputs and they're outlined [here](doc:input-types) \n\nInputs can optionally have a `description`, `default`, and `label`.  Inputs are assumed to be required automatically and will throw an error in the UI if not completed unless the field `\"required\": false` is included in the manifest for a given input.  \n\nValues must be supplied for each `input` within the `parameters` section of your `preview` unless the input has either a default value or specifies `\"required\": \"false\"`.  The value of each input is either the parameter's appropriate input type or an object describing further options for the field.\n\nFor example:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"\\\"inputs\\\": {\\n\\t\\\"sample_vol\\\": {\\n    \\\"type\\\":\\\"volume\\\",\\n    \\\"label\\\": \\\"Sample Volume\\\",\\n    \\\"description\\\": \\\"The volume of the sample\\\",\\n    \\\"default\\\": \\\"10:microliter\\\"\\n  },\\n\\t\\\"samples\\\": {\\n  \\t\\\"type\\\": \\\"aliquot+\\\",\\n  \\t\\\"label\\\": \\\"Samples to PCR\\\"\\n\\t},\\n\\t\\\"additives (optional)\\\": {\\n  \\t\\\"type\\\": \\\"aliquot\\\",\\n  \\t\\\"label\\\": \\\"Additives for PCR\\\",\\n    \\\"required\\\": false\\n\\t},\\n\\t\\\"gel\\\": {\\n    \\\"type\\\": \\\"bool\\\",\\n    \\\"label\\\": \\\"Run a gel?\\\",\\n   \\t\\\"default\\\": true\\n  }, \\n\\t\\\"gel_type\\\": {\\n    \\\"type\\\": \\\"choice,\\n    \\\"label\\\": \\\"Gel Type\\\",\\n    \\\"options\\\": [\\n      {\\n        \\\"name\\\": \\\"2% agarose\\\", \\n        \\\"value\\\": \\\"agarose(10,2%)\\\"\\n      },\\n      {\\n        \\\"name\\\": \\\"0.8% agarose\\\",\\n        \\\"value\\\": \\\"agarose(10,0.8%)\\\"\\n      }\\n     ]\\n  }\\n\\t\\\"pcr_gradient_top\\\": \\\"temperature\\\",\\n\\t\\\"pcr_gradient_bottom\\\": \\\"temperature\\\"\\n}\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\nFor more details check the [Input Types](doc:input-types)  page\n\n### preview\nThe `preview` field within a protocol's manifest is used to print Autoprotocol to standard out by providing the protocol's associated script (called by its `command_string`) with sample parameters.  This can be done by using the `transcriptic preview <protocol name>` command from the directory that contains your manifest.\n\n#### parameters\nThis section indicates the values for each `input` defined above, unless the input has either a default value or specifies `\"required\": \"false\"`.  The value of each input is either the parameter's appropriate input type or an object describing further options for the field.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"\\\"parameters\\\": {\\n\\t\\\"sample_vol\\\" : \\\"20:microliter\\\",  # optional, only required if deviating from default value\\n\\t\\\"samples\\\": [\\\"sample_container/A1\\\"],  # optional\\n  \\\"gel\\\": false, \\n  \\\"gel_type\\\": \\\"agarose(10,2%)\\\",  # must be specified since no default is given\\n\\t\\\"pcr_gradient_top\\\": \\\"64:celsius\\\",\\n\\t\\\"pcr_gradient_bottom\\\": \\\"52:celsius\\\"\\n}\\n\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\n#### refs\nThe refs stanza details containers used by the `preview` protocol. A ref must be in the form of:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"\\\"refs\\\":\\n\\t\\\"ref_name\\\":{\\n    \\\"type\\\":  <plate type>,\\n    \\\"store\\\":  <storage condition>\\n    \\\"aliquots\\\": {\\n    \\t\\\"0\\\": {\\n    \\t\\t\\\"volume\\\": \\\"100:microliter\\\",\\n    \\t\\t\\\"properties\\\": {\\n    \\t\\t\\t\\t\\\"foo\\\": \\\"bar\\\",\\n    \\t\\t\\t\\t...\\n  \\t\\t},\\n\\t\\t...\\n  \\t},\\n  },\\n\\t...\\n}\",\n      \"language\": \"json\"\n    }\n  ]\n}\n[/block]\nYou can also specify aliquots and their names and properties within the refs section if they are applicable to your script.  Read more about refs in the Structure section [here](http://autoprotocol.org/specification/).  All refs specified in this section must be used in your protocol.","excerpt":"","slug":"the-manifest","type":"basic","title":"The Manifest"}
The manifest file is used to provide metadata and parameters for packages uploaded to Transcriptic. It can be thought of as a markdown language you can use to create a graphical user interface for your protocols so that they can be parameterized and launched easily through the web app. The basic structure of a `manifest.json` file is as follows: [block:code] { "codes": [ { "code": "{\n \"format\": \"python\",\n \"license\": \"MIT\",\n \"protocols\": [\n {\n \"name\": \"sample5\",\n \"version\": \"1.0.0\",\n \"display_name\": \"Sample Protocol #5\", \n\t\t\t\"description\": \"This is a sample protocol.\",\n \"command_string\": \"python sample5.py\",\n \"inputs\": {},\n \"preview\": {\n \"refs\":{},\n \"parameters\": {}\n\t\t\t}\n }\n ]\n}\n", "language": "json", "name": "manifest.json" } ] } [/block] [block:callout] { "type": "info", "body": "A useful tool for editing your manifest can be found at http://jsoneditoronline.com" } [/block] ## Many protocols in one manifest A manifest may contain one or multiple protocols in its `protocols` array. The best way to organize a directory containing multiple protocols is to have the manifest file referring to all of them at the root of the directory and code for each of the protocols in separate subfolders. The `command_string` field should call each one accordingly. For example, if your language of choice is Python, your directory structure would look something like: ``` my_package/ protocol_1/ __init__.py protocol.py protocol_2/ __init__.py protocol.py manifest.json ``` and your `manifest.json` would call each protocol as a module: [block:code] { "codes": [ { "code": "{\n \"protocols\": [\n {\n \"name\": \"protocol1\",\n \"version\": \"1.1.2\",\n \"display_name\": \"My First Protocol\", \n \"command_string\": \"python -m protocol_1.protocol\",\n ...\n },\n {\n \"name\": \"protocol2\",\n \"version\": \"2.0.5\",\n \"display_name\": \"My Second Protocol\",\n \"command_string\": \"python -m protocol_2.protocol\",\n ...\n }\n ]\n ...\n}\n", "language": "json", "name": "manifest.json" } ] } [/block] ## Protocol specific information Here we will outline the various fields within a manifest: ### name This is a shortname for your protocol, usually one [CamelCased](http://en.wikipedia.org/wiki/CamelCase) word. This is the name you will use to refer to your protocol when you run `transcriptic preview` or `transcriptic analyze` from the command-line (more on that later). This name will appear in the protocol browser on secure.transcriptic.com unless you specify another name in the `display_name` field. ### command_string This is a string that represents exactly how you would run your protocol from the command-line from the directory that your manifest.json file is located in. Keeping it simple, assuming your protocol was in the same directory as your manifest.json file and was called `sample_protocol.py`, the command string would be `python sample_protocol.py`. ### parameters Parameters specified in this stanza get passed to the protocol script specified in the command string. Parameters must be passed in the format expected by their input type. ### inputs An input refers to an editable field on a protocol within the protocol browser, they will allow you to replace the parameters you hard-coded into the preview once the protocol is uploaded as a package to the web app. There are several types of inputs and they're outlined [here](doc:input-types) Inputs can optionally have a `description`, `default`, and `label`. Inputs are assumed to be required automatically and will throw an error in the UI if not completed unless the field `"required": false` is included in the manifest for a given input. Values must be supplied for each `input` within the `parameters` section of your `preview` unless the input has either a default value or specifies `"required": "false"`. The value of each input is either the parameter's appropriate input type or an object describing further options for the field. For example: [block:code] { "codes": [ { "code": "\"inputs\": {\n\t\"sample_vol\": {\n \"type\":\"volume\",\n \"label\": \"Sample Volume\",\n \"description\": \"The volume of the sample\",\n \"default\": \"10:microliter\"\n },\n\t\"samples\": {\n \t\"type\": \"aliquot+\",\n \t\"label\": \"Samples to PCR\"\n\t},\n\t\"additives (optional)\": {\n \t\"type\": \"aliquot\",\n \t\"label\": \"Additives for PCR\",\n \"required\": false\n\t},\n\t\"gel\": {\n \"type\": \"bool\",\n \"label\": \"Run a gel?\",\n \t\"default\": true\n }, \n\t\"gel_type\": {\n \"type\": \"choice,\n \"label\": \"Gel Type\",\n \"options\": [\n {\n \"name\": \"2% agarose\", \n \"value\": \"agarose(10,2%)\"\n },\n {\n \"name\": \"0.8% agarose\",\n \"value\": \"agarose(10,0.8%)\"\n }\n ]\n }\n\t\"pcr_gradient_top\": \"temperature\",\n\t\"pcr_gradient_bottom\": \"temperature\"\n}", "language": "json" } ] } [/block] For more details check the [Input Types](doc:input-types) page ### preview The `preview` field within a protocol's manifest is used to print Autoprotocol to standard out by providing the protocol's associated script (called by its `command_string`) with sample parameters. This can be done by using the `transcriptic preview <protocol name>` command from the directory that contains your manifest. #### parameters This section indicates the values for each `input` defined above, unless the input has either a default value or specifies `"required": "false"`. The value of each input is either the parameter's appropriate input type or an object describing further options for the field. [block:code] { "codes": [ { "code": "\"parameters\": {\n\t\"sample_vol\" : \"20:microliter\", # optional, only required if deviating from default value\n\t\"samples\": [\"sample_container/A1\"], # optional\n \"gel\": false, \n \"gel_type\": \"agarose(10,2%)\", # must be specified since no default is given\n\t\"pcr_gradient_top\": \"64:celsius\",\n\t\"pcr_gradient_bottom\": \"52:celsius\"\n}\n", "language": "json" } ] } [/block] #### refs The refs stanza details containers used by the `preview` protocol. A ref must be in the form of: [block:code] { "codes": [ { "code": "\"refs\":\n\t\"ref_name\":{\n \"type\": <plate type>,\n \"store\": <storage condition>\n \"aliquots\": {\n \t\"0\": {\n \t\t\"volume\": \"100:microliter\",\n \t\t\"properties\": {\n \t\t\t\t\"foo\": \"bar\",\n \t\t\t\t...\n \t\t},\n\t\t...\n \t},\n },\n\t...\n}", "language": "json" } ] } [/block] You can also specify aliquots and their names and properties within the refs section if they are applicable to your script. Read more about refs in the Structure section [here](http://autoprotocol.org/specification/). All refs specified in this section must be used in your protocol.