App Metadata: dxapp.json
The file dxapp.json is a DNAnexus application metadata file. Its presence in a directory tells DNAnexus tools that it contains DNAnexus app source code (i.e., it's a project directory). The file's format is defined by convention and operationally by DNAnexus tools that use it (usually invoked through dx build and dx build --create-app]).
The format of the file closely resembles that of the corresponding calls to /applet/new and /app/new, except for some differences as noted below. Fields found in dxapp.json but not recognized by the build tools are passed through to the API methods.
The next section is a detailed example showing most of the commonly-used fields.

Annotated Example

The following lists the contents of an example dxapp.json to be provided in a directory for use with the dx build command. For fields that are marked for apps only, it is harmless to provide them when building applets; they will simply only take effect when building apps.
Note that comments as shown below are not valid in the JSON format but are provided here for easy reference.
1
{
2
"name": "mapper", # Simple name; cannot be changed across versions of an app
3
4
"title": "Simple Read Mapper", # Human-readable name (shown on the App's page and used as the default
5
# job name)
6
7
"summary": "Maps reads to a genome", # One-liner description of what the app(let) does
8
9
"description": "This app...", # (optional) Longer description of what the app(let) does; if not
10
# provided, dx build will inline the Readme.md file if available
11
12
"developerNotes": "...", # (optional) Detailed notes covering extra details; if not provided,
13
# dx build will inline the Readme.developer.md file if available
14
15
"details": { # (optional) This can contain arbitrary metadata, but there are some
16
"contactEmail": "[email protected]" # key/value pairs that are recognized as conventions by the website
17
}, # when rendering your app, e.g. for displaying contact information
18
19
"dxapi": "1.0.0", # The version of the API that your app uses
20
21
"version": "0.0.1", # Apps only: version of the app that is being built
22
23
"categories": ["Read Mapping"], # (optional) Apps only: list of categories describing the app (see
24
# below for a list of recognized categories)
25
26
"inputSpec": [ # Input specification (see API documentation)
27
# An array:int input "1,2,3" would be launched with the input [1, 2, 3]
28
# An array:strin "1,2,3" would be launched with the input ["1", "2", "3"]
29
{
30
"name": "reads",
31
"class": "file",
32
"patterns": ["*.fastq", "*.fastq.gz"],
33
"help": "Input FASTQ files ... ",
34
"optional": false
35
},
36
{
37
"name": "genomeindex_targz",
38
"label": "BWA reference genome index",
39
"help": "A file ...",
40
"class": "file",
41
"patterns": ["*.bwa-index.tar.gz"],
42
"suggestions": [
43
{
44
"name": "DNAnexus Reference Genomes",
45
"project": "project-BQpp3Y804Y0xbyG4GJPQ01xv",
46
"path": "/"
47
}
48
],
49
"optional": false
50
},
51
{
52
"name": "reads_type",
53
"class": "string",
54
"default": "paired-end",
55
"choices": ["single-end", "paired-end"],
56
"group": "Advanced Options"
57
}
58
],
59
60
"outputSpec": [ # Output specification (see API documentation)
61
{
62
"name": "mappings",
63
"class": "file",
64
"patterns": ["*.bam"]
65
}
66
],
67
68
"runSpec": { # Run specification (for more details, see the API documentation)
69
70
"interpreter": "python3", # Either "bash" or "python3" to indicate the interpreter for which
71
# the script in "file" was written
72
73
"file": "src/mapper.py", # Path to the script that will be run when this app(let) is run
74
"restartableEntryPoints": "all", # All entry points may be restarted if a restartable error occurs
75
"assetDepends": [
76
{
77
78
"id": "record-Bq320600kXGxY7PyB43GZ69j"
79
# Asset bundle record ID
80
},
81
{
82
"name": "qiime_asset", # (optional) Asset bundle record name
83
84
"version": "0.0.1", # (optional) Asset bundle record version number
85
86
"project": "project-Bq1pqV00kXGgzp45j4jGyYY7",
87
# (optional) ID of the project containing the asset bundle record
88
"folder": "/records" # (optional) Folder in the project containing the asset bundle record.
89
} # By default the folder is "/"
90
],
91
"systemRequirements": { # (optional, deprecated, moved to "regionalOptions") Request different
92
# instance types for different entry points
93
94
"main": { # "main" here is the name of the entry point that is called when an
95
"instanceType": "mem1_ssd1_x4" # app(let) is run
96
},
97
98
"process": { # "process" is the name of an entry point (used when spawning a new job
99
"instanceType": "mem1_ssd1_x4" # via /job/new that runs the function called "process")
100
},
101
102
"*": { # "*" indicates that the request applies to all other entry points
103
"instanceType": "mem3_ssd1_x4",# (when calling /job/new any function value other than "main" and "process")
104
"clusterSpec": { # (optional) request a cluster of instances
105
"type": "dxspark", # "dxspark", "apachespark","generic"
106
"version": "3.2.0", # "2.4.4" or "3.2.0" for spark, not present for generic
107
"initialInstanceCount": 3, # Size of the cluster (min 1) including the master
108
"ports": "1000, 1100-1200", # (optional) Ports/port-ranges to open for communication between nodes in the cluster
109
"bootstrapScript": "./bootstrap.sh" # (optional) Script to run on all nodes before running app code on master node
110
}
111
} #
112
},
113
114
"executionPolicy": { # (optional) Options governing job restart policy
115
"restartOn": {
116
"*": 3 # Restart automatically up to 3 times for system errors
117
}
118
},
119
120
"timeoutPolicy": { # (optional) User-specified timeout policy for a job running this executable.
121
122
"main": { # "main" here is the name of the entry point that is called when this executable
123
"hours": 12 # is run. The "main" entry point will timeout after 12 hours.
124
},
125
126
"*": { # "*" indicates that all other entry points except those explicitly specified in
127
"hours": 4, # `timeoutPolicy` (i.e. "main") will timeout after 4 hours 30 minutes.
128
"minutes": 30
129
}
130
},
131
132
"distribution": "Ubuntu", # The flavor of Linux that your app(let) will run on. Supported value: "Ubuntu"
133
"release": "16.04", # The release of the Linux distribution your app(let) will run on.
134
# Supported values: "20.04", "16.04".
135
"version": "1", # Default: "0". A triplet of (distribution, release, version)
136
# uniquely identifies an application execution environment. Supported versions:
137
# ("Ubuntu","20.04","0")
138
# ("Ubuntu","16.04","0")
139
# ("Ubuntu","16.04","1") (includes full python3 support)
140
141
"execDepends": [ # (optional) A list of packages that your app(let) requires to be
142
# installed before it can be run
143
{
144
"name": "samtools" # "samtools" is an APT package name (other package managers also
145
} # supported; see documentation on the run specification for details)
146
]
147
},
148
149
"resources": "project-BBF4Jp80vVky55Vvgkb0028v",
150
# (optional, deprecated, moved to the "regionalOptions" field) Apps only: request
151
# some resource(s) to be made (privately) accessible to the app when it is run;
152
# can be a project ID or a list of data object IDs. It can be used only for apps
153
# enabled in a single region and when "regionalOptions" field is not specified.
154
155
"ignoreReuse": true, # (optional) Whether job reuse is disabled by default for this applet or app.
156
# Can be overriden at runtime.
157
158
"openSource": true, # (optional) Apps only: Whether the contents of this app version's
159
# resources container should be viewable by all members of the app's
160
# developers and authorized users
161
162
"httpsApp": { # (optional) externally expose jobs to the internet via an HTTPS proxy
163
# at https://job-xxxx.dnanexus.cloud/
164
"ports": [443, 8080, 8081], # Array of ports to allow access. Allowed values are 443, 8080, 8081
165
"shared_access": "VIEW" # Restrict access to users with project access VIEW, CONTRIBUTE, ADMINISTER, or NONE to limit to the launching user
166
},
167
168
"access": { # (optional) Request that the app(let) be given additional access
169
# permissions
170
171
"project": "CONTRIBUTE", # (optional) Give the app(let) CONTRIBUTE access to the project in
172
# which it is run. By default, an app will receive NO access, or if
173
# you build this as an applet, it will receive VIEW access.
174
175
"allProjects": "VIEW", # (optional) Give the app(let) VIEW access to all projects that the
176
# user running the app can access. Use this carefully.
177
178
"network": [ # (optional) Give the app(let) network access to all domains; you can
179
"*" # also list specific domains such as "github.com".
180
],
181
182
"developer": true # (optional) Give the app(let) permissions to act as a developer on
183
# behalf of the user (e.g. it will be able to create new apps and
184
# access unpublished apps)
185
},
186
187
"developers": [ # Apps only: these users will be allowed to publish new versions of
188
"user-you" # this app and perform other administrative functions.
189
],
190
191
"authorizedUsers": [ # Apps only: any published version of this app will be runnable by the
192
"user-alice", # developers of the app, and by user-alice and user-bob. (Access to
193
"user-bob" # an applet is determined by access to the project containing the
194
], # applet.)
195
196
# In the case of apps: set this field to allow your app to be run in more
197
# than one region. Provide as keys all the regions in which you wish the
198
# app to be enabled. At a minimum, supply an empty object mapping {}
199
# as the corresponding value. Within each value, you may also supply
200
# any of the keys "systemRequirements", "bundledDepends",
201
# "assetDepends", or "resources". The corresponding values will be treated
202
# as if you had supplied them in the run specification above, but only
203
# for the associated region.
204
#
205
# In the case of applets: request specific "systemRequirements"
206
# in the region in which the applet will be built.
207
#
208
# You can use this to request different instance types that might be
209
# available in different clouds, or to supply copies of app resources
210
"regionalOptions": { # that are colocated with the specific region where the app will be
211
"aws:us-east-1": { # run.
212
"systemRequirements": {"*": {"instanceType": "mem2_ssd1_x2"}},
213
"bundledDepends": [{"name": "bundle.tar.gz", "id": {"$dnanexus_link": "file-xxxx"}}],
214
"assetDepends": [{"id": "record-yyyy"}],
215
"resources": "project-zzzz"
216
},
217
"azure:westus": {
218
"systemRequirements": {"*": {"instanceType": "azure:mem2_ssd1_x2"}},
219
"bundledDepends": [{"name": "bundle.tar.gz", "id": {"$dnanexus_link": "file-zzzz"}}],
220
"assetDepends": [{"id": "record-aaaa"}],
221
"resources": ["file-aaaa", "file-bbbb"]
222
}
223
}
224
225
}
Copied!
Other options for the /applet/new and /app/new calls, such as specifying in which project or folder to create an applet, are populated via command-line flags of dx build.

Specification

name

The name string The unique name of the applet / app. The name can have lower case letters, numbers, -, and _ but cannot have spaces.
If the applet is published into an app, then its ID will be of the form app-[name]/[version]. An app's name cannot be changed across versions.
Example:
1
{
2
...
3
"name": "bwa_mem_fastq_read_mapper",
4
...
5
}
Copied!

title

title string (optional) A human-readable name of the app(let). If published as an app, this name will be shown on the Apps page and as the default job name.
Example:
1
{
2
...
3
"title": "BWA-MEM FASTQ Read Mapper",
4
...
5
}
Copied!

summary

summary string (optional) A one-liner description of the app(let). If published as an app, this summary will be displayed under the app name on the Apps page.
Example:
1
{
2
...
3
"summary": "Maps FASTQ reads to a reference genome with the BWA-MEM algorithm.",
4
...
5
}
Copied!

description

description string (optional) Longer description of what the app(let) does. If not provided, dx build will inline the Readme.md file, if available.
Example:
1
{
2
...
3
"description": "This app maps FASTQ reads to a reference genome ... inputs ...",
4
...
5
}
Copied!

developerNotes

developerNotes string (optional) Detailed notes covering extra details. If not provided, dx build will inline the Readme.developer.md file, if available.
Example:
1
{
2
...
3
"developerNotes": "...",
4
...
5
}
Copied!

details (developer and contact info, and other metadata)

details string (optional) This can contain arbitrary metadata, but there are some key/value pairs that are recognized as conventions by the website when rendering your app, e.g. for displaying contact information. Recognized metadata fields include the following:
  • Author contact information
  • Upstream executable version number (i.e. bwa-mem 0.7.12)
  • Upstream author name
  • URL for app executable
  • Upstream licenses
  • Change Log
  • Citations for papers
Example:
1
{
2
...
3
"details": {
4
"contactEmail": "[email protected]",
5
"citations": [ "doi:10.1093/bioinformatics/btp352"],
6
"upstreamVersion": "0.9.12",
7
"upstreamAuthor": "Alice Bob",
8
"upstreamUrl": "http://foo.bar.edu/",
9
"upstreamLicenses": ["GLPv3"],
10
"whatsNew": "## Changelog\n* Optionally markdown formated"
11
}
12
...
13
}
Copied!

dxapi

dxapi string (optional) The version of the API that your app uses.
Example:
1
{
2
...
3
"dxapi": "1.0.0",
4
}
Copied!

version

version string Apps only: The version of the app to be built. This version number must be unique from all other versions of the app (published or not).
Example:
1
{
2
...
3
"version": "0.0.2",
4
}
Copied!

categories (user-browseable categories)

You can specify any categories you wish for your app in the "categories" field of the dxapp.json. However, the following categories are specially recognized by DNAnexus, and authorized users of your app can use them to browse for your app in the App Store if you specify any of them:
  • Annotation
  • Assembly
  • Debugging
  • Export
  • Import
  • Mappings Manipulation
  • Read Manipulation
  • Read Mapping
  • Reports
  • RNA-Seq
  • Statistics
  • Structural Variation
  • Variation Calling
Example:
1
{
2
...
3
"categories": [
4
"Read Mapping"
5
],
6
}
Copied!

inputSpec and outputSpec

JSON array containing the specifications for each input to the app. These fields are required for apps and highly recommended when developing applets. The full documentation for specifying an input or output specification can be found here.
If you do choose to exclude an input (output) specification for an applet (i.e. one or more of the keys inputSpec and outputSpec is missing), this means that the system will perform no checking on the input (output) provided to (returned by) the applet, respectively. Note, however, that applets that do not have both an input and output specification cannot be added as a stage in a workflow.

runSpec (entry point and dependencies)

The runSpec field specifies your app's entry and the interpreter used to evaluate it:
1
{ ...,
2
"runSpec": {
3
"interpreter": "python3",
4
"file": "src/code.py"
5
},
6
...
7
}
Copied!
In the above example, the "runSpec.file" parameter provides the path to a Python file that contains your application logic.
In this case, we've provided Python code (code.py) that uses the DNAnexus Python 3 execution template (indicated in the interpreter field). This template takes care of parsing your app's input from the DNAnexus execution environment, handling possible errors, and saving your app's output. See the example applications for examples of the entry point Python function signatures.
For more details about execution templates and running code in the execution environment, see the Execution Environment Reference.

version (versioning your app)

You can designate a specific version number, such as 3.1.41-rc.1, to identify each build of your app.
We recommend following the Semantic Versioning conventions for numbering the versions of your app. Semantic Versioning also specifies how you should change the version number for various kinds of updates to your app (that is, bug-fix only, backwards compatible, or backwards incompatible). Using the Semantic Versioning guidelines will help users and other developers to understand when it is safe to move between different versions of your app.

access field (app permissions)

In order to both make reproducibility guarantees feasible and protect user privacy, apps are generally heavily restricted in what data they can read and write. Apps may request relaxation of these restrictions.
The full documentation on the options that can be requested can be found here.
See also the App Permissions Guide for more information about the permissions available and their implications.

authorizedUsers field (who can access your app)

You can specify who can describe and run your app by providing a list of users. The default access list is the empty list [], which indicates that no one except the developers of the app can find and run your app, even if it has been published. You may provide a list of users and/or organizations here to grant them access the app.
Note: the access list is shared for all past and future versions of the app but can be modified at any time. If you need to create another version of your app which has a different access list, you will need to publish it separately under a different name.
You can also edit the list of authorized users after you've built and published an app by using the dx add users and dx remove users commands. However, if you (or another developer) rebuilds the app with authorizedUsers in the dxapp.json file, the access list will be overwritten to match the one found in the file.

regionalOptions field (which regions the app can be run in)

You can specify what regions the app can be run in, and specify advanced options that control the app's behavior in multiple regions. The regionalOptions field should be a mapping with keys corresponding to each region in which the app should be runnable. (A region is given by a string like "aws:us-east-1"; see Regions for more information about regions.) If you don't specify this field, the app will be enabled in only one region: the region of your project context when the app is built.
The values associated with each key are themselves mappings. In the most basic usage, you can specify an empty mapping for each region. This is generally sufficient to allow apps that don't use certain advanced features to be run in multiple regions.
For apps that make use of bundled dependencies, additional resources, or specify that they should run on specific instance types, each value of regionalOptions may contain the following keys and values:
  • systemRequirements mapping Request specific instance types and (optional) define a clusterSpec for some of the entry points of the app when it is run in the corresponding region.
  • bundledDepends list bundled dependencies for the corresponding region. For the syntax of this field, see the discussion of bundledDepends in the run specification.
  • assetDepends list asset dependencies for the corresponding region. See the assetDepends field above for the syntax of this field.
  • resources string or array of strings Either a string containing the ID of a project which will be snapshotted into a resources container, or an array of data object IDs, which will all be cloned into the root folder of the resources container. All specified objects must reside in the specified region and will be available to the app when it is run in that region.
If you specify a value for a key, say "systemRequirements", you must do so in all regions, and you may not specify the same key in the run specification.
Last modified 1mo ago