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 3 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

Each notebook should be treated as single component/service that use its own dependencies, therefore when storing notebooks, they should be stored each in a specific repo.
pacospace marked this conversation as resolved.
Show resolved Hide resolved

## 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)
* 2. Jupyter notebook with dependencies embedded in json file of the notebook (conflict with local requirements (Pipfile/Pipfile.lock))
* 3. Jupyter notebook without dependencies embedded in json file but with Pipfile/Pipfile.lock always present (Jupyter notebook and requirements are decoupled)
* 4. Jupyter notebook with sha256 embedded in json file that matches Pipfile/Pipfile.lock sha256 always present (Jupyter notebook and requirements are coupled)

## Decision Outcome

The option select is 4. because:

* avoid conflicts in dependencies and enforce security also
* enforce reproducibility
* enforce traceability between notebook and requirements

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

* Satisfy reproducibility, traecability, shareability.
pacospace marked this conversation as resolved.
Show resolved Hide resolved
* Each notebook need to be treated as single service/task with its own dependencies.
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 -->