Reimplement `cookiecutter-docker-stacks` without cookiecutter

[mathbunnyru]

cookiecutter-docker-stacks is a project, which allows other people to easily create their custom images. It uses cookiecutter to allow to use part of the repo as a template for newly created repo.

I would like to suggest another approach:

• No cookiecutter or another 3rd part technology.
• Actually implement working example of custom-notebook.
• Suggest people to fork the repo and just to change a few lines of code manually.
• Use a few files from jupyter/docker-stacks

Pros:

• No knowledge of cookiecutter needed.
• People will create their new repo in one click (instead of downloading and dealing with cookie cutter)
• Instead of having part of repo in repo, we will have fully functional example
• It's easier to test, easier to keep up-to-date (using dependabot / pre-commit.ci) and so on
• Because it will be a forkable repo, other custom notebook will be able to use our updates easily
• We can see statistics of forks and also easily find other projects using our stacks as a base
• People will be able to send us PRs improving our code

Cons:

• We will ask people to manually change a few lines of code, instead of using cookiecutter. I thinks it's possible to have just a few lines of code like this.

Implementation details:

• I can create the new repo on my own with minimal example
• I will be perfectly find with moving my repo to jupyter org when it is ready
• Archive existing repo (with a link no new repo)
• New repo will have issues enabled, because it might have issues on its own (this issue should actually belong there).
• Also, it would be nice to have a 15-lines python script to update files we use from (jupyter/docker-stacks repo), like tests/conftest.py

Please, tell me what you think.

[mathbunnyru]

@consideRatio could you share what you think about this proposal?

[consideRatio]

Thanks for thinking about this! I'm :+1: for this!!

I'm not clearly overviewing the kind of changes that can be relevant in this repo, but if this is mostly documentation this change suggestion makes perfect sense to me! It sounds like a strategy that is easier to sustain maintenance wise than having a dedicated repo people use to generate files from.

[mathbunnyru]

My WIP: https://github.com/mathbunnyru/custom-notebook-image Built image: https://hub.docker.com/repository/docker/mathbunnyru/custom-notebook

Current TODO-list: https://github.com/mathbunnyru/custom-notebook-image/issues/1

[mathbunnyru]

I implemented everything another way. https://github.com/mathbunnyru/custom-notebook

I created the upstream_project branch, where a full copy of the upstream project is stored. In the main branch there are only files which might be needed for your own custom image.

Built image: https://hub.docker.com/repository/docker/mathbunnyru/custom-notebook

Our use-case:

1. Pull the upstream changes to the upstream_project branch.
2. Merge this branch to main branch.
3. Profit.

Users:

1. Fork from this repo.
2. Change a few lines.
3. Whenever they want, merge the custom-notebook changes to their image.

The only thing left is to update the docs.

@consideRatio could you take a look please?

[consideRatio]

@mathbunnyru I think a clear proposal like suggesting users that want to make their own image fork and maintain a fork is very reasonable. I tried visiting https://github.com/mathbunnyru/custom-notebook and https://github.com/mathbunnyru/custom-notebook-image but got 404 - are they private? But, if they were found, what should i review more specifically in them - assuming they are forks and mostly the same?

[mathbunnyru]

They are not forks of this repo (otherwise people will not be able to have fork of the original repo if they need). First one is public and should work (https://github.com/mathbunnyru/custom-notebook). Second one is already deleted (I don't need it anymore). Could you try once more please?

I would like you to look at the structure of the repo and the files.

[consideRatio]

Ah, the proposal is to provide an centralized example project that whoever clones can keep keep updated with a centrally maintained example project.

I think very critical is to define what should be part of the central project then, and looking at the proposed central example project, I'm afraid that bundling tests/tagging/formatting&linting from jupyter/docker-stacks will be unsustainable.

I think this is essential for a new centralized example project users can update against.

• end users:
  • ease of understanding why and how to fork this example project, and then understanding the content itself - less can be more!
  • ease of initial setup (fork the example project)
  • ease of updating the setup (git rebase or git merge)
  • ease of automating the publishing of a single image with modification
• docker-stacks maintainers:
  • low maintenance

I worry that going beyond this will lead to too much maintenance or too much complexity to document and convey to end users.

[mathbunnyru]

Thank you, Erik! I understand your point.

I wanted to provide something "production-ready" to make our example project work for people, who intend to create their own docker images for many users and so on. Do you think we should simply drop all the tests, tagging, formatting&linting?

[mathbunnyru]

Hi @consideRatio! I removed almost all the tests and all the tagging from my project. I've left some linting, because it will help me as a maintainer, to make sure that the code has good quality. Please take a look.

https://github.com/mathbunnyru/custom-notebook

I think the only thing left to be done is to update this section of docs: https://jupyter-docker-stacks.readthedocs.io/en/latest/contributing/stacks.html#creating-a-project

[mathbunnyru]

Fun fact: I've used one of the most modern GitHub features again. https://github.blog/changelog/2022-09-27-github-actions-additional-information-available-in-github-event-payload-for-scheduled-workflow-runs/ https://github.com/mathbunnyru/custom-notebook/blob/main/.github/workflows/docker-build-test-publish.yml#L5

Now, by default, the docker image will be called as the repo. And GitHub allowed to choose the name of a fork half a year ago, so this should work really well for our users. https://github.blog/changelog/2022-04-12-you-can-now-name-your-fork-when-creating-it/

[mathbunnyru]

@consideRatio please, take a look here. I think currently it's a good balance between no features and too many features.

Repo (I've recreated it from scratch): https://github.com/mathbunnyru/custom-notebook DockerHub: https://hub.docker.com/r/mathbunnyru/custom-notebook

[mathbunnyru]

I think there is nothing to do here - I don't think many people are using cookie cutter or will use my repo as an example, so closing this issue.