Skip to content

Commit c47ebfa

Browse files
[proposal] Sharing code between Dev Container Features (#209)
* include property * Update features-library.md * Apply suggestions from code review Co-authored-by: Brigit Murtaugh <[email protected]> * clarify * update proposal to mirror repo structure * clean up proposal --------- Co-authored-by: Brigit Murtaugh <[email protected]>
1 parent 42ec3d7 commit c47ebfa

File tree

1 file changed

+150
-0
lines changed

1 file changed

+150
-0
lines changed

proposals/features-library.md

Lines changed: 150 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,150 @@
1+
# Sharing code between Dev Container Features
2+
3+
ref: https://github.com/devcontainers/spec/issues/129
4+
5+
# Motivation
6+
7+
The current model for authoring Features encourages significant copy and paste between individual Features. Most of the Features published under the `devcontainers/features` namespace contain approximately 100 lines of [identical helper functions](https://github.com/devcontainers/features/blob/main/src/azure-cli/install.sh#L29-L164) before the first line of the script is executed. The process of maintaining these helper functions is tedious, error-prone, and leads to less readable Features.
8+
9+
Additionally, [members of the Feature authoring community have expressed interest in sharing code between Features](https://github.com/orgs/devcontainers/discussions/10). Exploring the source code of self-published Features, it is evident that many authors have copy/pasted code from other Features. This is a sign that there is a need for a more efficient way to share code between Features.
10+
11+
# Goal
12+
13+
Provide a generic and simple way to share code between Features.
14+
15+
# Proposals
16+
17+
## [Proposal A] Add: `include` property to `devcontainer-feature.json`
18+
19+
Add an `include` property to the `devcontainer-feature.json`. This will be honored during the Feature [packaging stage](https://containers.dev/implementors/features-distribution/#packaging).
20+
21+
The contents of the provided relative path is copied into the packaged Feature archive. Files or directories are recursively copied into the archive following the same directory structure as in the source code.
22+
23+
The relative path must not escape the root directory - if this is attempted, the packaging stage will fail.
24+
25+
Property | Type | Description
26+
--- | --- | ---
27+
`include` | `string[]` | An array of paths relative to the directory containing this `devcontainer-feature.json`. If the element is a folder, it is copied recursively. Must be prefixed with `.` or `..` to indicate the provided string is relative path.
28+
29+
### Example
30+
31+
```json
32+
{
33+
"name": "featureA",
34+
"version": "0.0.1",
35+
"include": [
36+
"../../utils/",
37+
"../../company-welcome-message.txt"
38+
]
39+
}
40+
```
41+
42+
## [Proposal B] Change: Structure of packaged Feature
43+
44+
Change the file structure of the packaged Feature to mirror the directory structure of the source code. This will simplify the implementation of **Proposal A** and keep the relative paths consistent before and after packaging.
45+
46+
When running the packaging step, each Feature is packaged separately under `./src/<FeatureID>`. Other included directories will be copied into the root of the packaged artifact as indicated in **Proposal A**.
47+
48+
An implementation should resolve the `devcontainer-feature.json` by checking for its presence in the following order of precedence:
49+
50+
- `./src/<feature-id>/devcontainer-feature.json`
51+
- `devcontainer-feature.json`
52+
53+
From here forward, the proposed format will be used during the packaging step. For backwards compatibility, the existing format (with a `devcontainer-feature.json` at the top level) will be supported.
54+
55+
### Example
56+
57+
Given this example repository containing a collection of Features.
58+
59+
```
60+
.
61+
├── images
62+
│ ├── 1.png
63+
│ ├── 2.png
64+
├── company-welcome-message.txt
65+
├── utils
66+
| ├── common.sh
67+
│ └── helpers
68+
│ ├── a.sh
69+
│ └── ...
70+
|
71+
├── src
72+
│ ├── featureA
73+
│ │ ├── devcontainer-feature.json
74+
│ │ ├── install.sh
75+
│ │ └── ...
76+
│ ├── featureB
77+
│ │ ├── devcontainer-feature.json
78+
│ │ └── install.sh
79+
│ │ └── ...
80+
| ├── ...
81+
│ │ ├── devcontainer-feature.json
82+
│ │ └── install.sh
83+
│ │ └── ...
84+
├── ...
85+
```
86+
87+
When packaging Feature A (shown above in **Proposal A**), the resulting published archive will be structured as follows:
88+
89+
```
90+
.
91+
├── company-welcome-message.txt
92+
├── utils
93+
| ├── common.sh
94+
│ └── helpers
95+
│ ├── a.sh
96+
│ └── ...
97+
|
98+
├── src
99+
│ ├── featureA
100+
│ │ ├── devcontainer-feature.json
101+
│ │ ├── install.sh
102+
│ │ └── ...
103+
```
104+
105+
The packaging step recursively copies the contents of the `utils` folder into the resulting archive. Additionally, the `company-welcome-message.txt` is packaged and distributed with the Feature.
106+
107+
Note that the `images` folder is not included in the packaged Feature. This is because the `images` folder is not included in the `include` property of the `devcontainer-feature.json` file.
108+
109+
#### Using an included script in a Feature
110+
111+
The following example shows how a Feature could include a `utils` folder that contains a `common.sh` file.
112+
113+
```bash
114+
# utils/common.sh
115+
function common_function() {
116+
echo "Hello, '$1'"
117+
}
118+
```
119+
120+
```bash
121+
# src/featureA/install.sh
122+
123+
# Include common functions
124+
source "../../utils/common.sh"
125+
126+
# Use common function
127+
common_function "devcontainers"
128+
```
129+
130+
-----
131+
132+
# Possible Extensions
133+
134+
This section provides hints to possible future work that could extend the proposal above. These are not part of the proposal, but are provided to help the community understand the potential future impact of this proposal.
135+
136+
## Distributing shared library Features
137+
138+
In an effort to reduce the need for authors to copy/paste auxillary scripts between Feature namespaces, provide the ability to publish "library" Features. These Features would be published [following the Feature distribution spec](https://containers.dev/implementors/features-distribution/#distribution) under a new manifest type.
139+
140+
A "library" can be included in a Feature's `include` property as an alternative to a relative path. By itself, a "library" Feature would not be installable.
141+
142+
```json
143+
144+
{
145+
"name": "featureA",
146+
"version": "0.0.1",
147+
"include": [
148+
"ghcr.io/devcontainers/features/utils:0.0.1"
149+
]
150+
}

0 commit comments

Comments
 (0)