kopia lustrzana https://github.com/jupyterhub/repo2docker
27 wiersze
1.1 KiB
Markdown
27 wiersze
1.1 KiB
Markdown
# Adding a new buildpack to repo2docker
|
|
|
|
A new buildpack is needed when a new language or a new package manager should be
|
|
supported. Existing buildpacks are a good model for how new buildpacks
|
|
should be structured.
|
|
|
|
## Criteria to balance and consider
|
|
|
|
Criteria to balance are:
|
|
|
|
1. Maintenance burden on repo2docker.
|
|
2. How easy it is to use a given setup without support from repo2docker natively.
|
|
There are two escape hatches here - `postBuild` and `Dockerfile`.
|
|
3. How widely used is this language / package manager? This is the primary tradeoff
|
|
with point (1). We (Binder / Jupyter) team do not want to make new formats
|
|
as much as possible, so ideally we can just say 'X repos on binder already use
|
|
this using one of the escape hatches in (2), so let us make it easy and add
|
|
native support'.
|
|
|
|
## Adding libraries or UI to existing buildpacks
|
|
|
|
Note that this doesn't apply to adding additional libraries / UI to existing
|
|
buildpacks. For example, if we had an R buildpack and it supported IRKernel,
|
|
it is much easier to
|
|
just support RStudio / Shiny with it, since those are library additions than entirely
|
|
new buildpacks.
|