Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce ADR for dependencies management in Jupyter notebooks #282

Merged
merged 5 commits into from
Nov 12, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions docs/0000-dependencies-management-jupyter-notebooks.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
# Dependencies management in Jupyter Notebooks

## Context and Problem Statement

How to guarantee reproducibility of Jupyter Notebooks?

In order to allow any user to re run the notebook with similar behaviour, it's important that each notebook is shipped with dependencies requirements
that include direct and transitive dependencies. This would also enforce and support security, reproducibility, traecability.
pacospace marked this conversation as resolved.
Show resolved Hide resolved

Notebooks should be treated as component/service that use their own dependencies, therefore when storing notebooks,
they should be stored with dependencies so that an image can be built to run them or they can be shared and reused by others.

## Decision Drivers <!-- optional -->

* user prospective
* reproducibility
* traecability
pacospace marked this conversation as resolved.
Show resolved Hide resolved

## Considered Options

* 1. Jupyter notebook without dependencies (no reproducibility at all)
* 2. Jupyter notebook without dependencies embedded in json file but with Pipfile/Pipfile.lock always present (no reproducibility if I share the notebook)
* 3. Jupyter notebook with dependencies embedded in json file of the notebook that can be optionally extracted if the user wants.

## Decision Outcome

The option selected is 3. because:

* enforce reproducibility
* enforce traceability between notebook

### Positive Consequences <!-- optional -->

* Satisfy reproducibility, traecability, shareability.
pacospace marked this conversation as resolved.
Show resolved Hide resolved
* Notebooks are coupled with dependencies in their metadata.
* If more notebooks are present, a common Pipfile can be created with a button that can automatically extract from all notebook dependencies and new common Pipfile.lock will be created. This would allow creation of an image that can run the notebooks.
74 changes: 74 additions & 0 deletions docs/template.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,74 @@
# [short title of solved problem and solution]

* Status: [proposed | rejected | accepted | deprecated | … | superseded by [ADR-0005](0005-example.md)] <!-- optional -->
* Deciders: [list everyone involved in the decision] <!-- optional -->
* Date: [YYYY-MM-DD when the decision was last updated] <!-- optional -->

Technical Story: [description | ticket/issue URL] <!-- optional -->

## Context and Problem Statement

[Describe the context and problem statement, e.g., in free form using two to three sentences. You may want to articulate the problem in form of a question.]

## Decision Drivers <!-- optional -->

* [driver 1, e.g., a force, facing concern, …]
* [driver 2, e.g., a force, facing concern, …]
* … <!-- numbers of drivers can vary -->

## Considered Options

* [option 1]
* [option 2]
* [option 3]
* … <!-- numbers of options can vary -->

## Decision Outcome

Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].

### Positive Consequences <!-- optional -->

* [e.g., improvement of quality attribute satisfaction, follow-up decisions required, …]
* …

### Negative Consequences <!-- optional -->

* [e.g., compromising quality attribute, follow-up decisions required, …]
* …

## Pros and Cons of the Options <!-- optional -->

### [option 1]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 2]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

### [option 3]

[example | description | pointer to more information | …] <!-- optional -->

* Good, because [argument a]
* Good, because [argument b]
* Bad, because [argument c]
* … <!-- numbers of pros and cons can vary -->

## Links <!-- optional -->

* [Link type] [Link to ADR] <!-- example: Refined by [ADR-0005](0005-example.md) -->
* … <!-- numbers of links can vary -->

<!-- markdownlint-disable-file MD013 -->