Container name

[mmh352]

One other thing I noticed, in the build, I keep seeing <none> as the image name (maybe if I don't tag it? I think if I do tag it it gets the name mmh352/$CODE-$PRESENTATION), which means i need to run up a container by referencing the image ID not name.

Two observations about that:

1. May be useful to allow setting of something other than the mmh352 component;
2. May be useful to allow setting of something other than the $CODE-$PRESENTATION component

Generally, give folk (optional, away from default) control over how they create IMAGE_NAME = ORG/CONTAINER:TAG.

Originally posted by @psychemedia in https://github.com/mmh352/ou-container-builder/issues/7#issuecomment-831954265

[mmh352]

This is by design. The tool is opinionated and designed for a very specific use-case. By not allowing for any variation, this means that instructions for running the container can then be shared across modules, because all modules will be accessible at the same account/code-presentation location. (The "mmh352" bit is a placeholder. When I have set up the OU-specific image repository, then that will be set as the default.)

Where creators, for whatever reason, want a different account/repository/tag structure, they should use the docker commands to add further tags.

[psychemedia]

The opinionation (?) is useful, but also can feel limiting / constraining.

When I am working on my machine and have my own local way of organising/naming things, and various Dockerhub orgs (or local hubs) I can try things out on as test distributable containers, it would be more convenient during development if I could do that in the config file. Otherwise, I have to run extra docker commands, or write scripts to automate creating images with names that work for you but not for me that I have to then rename, or even create a local branch (or fork) of the repo using my own opinionated name not yours ;-)

In terms of potential scope, the tool is a (really useful) general one, albeit being developed with a specific use case you have in mind (I suspect my imagined uses are more general; eg helping folk create Jupyter run containers in general).

All I'm saying is, the specificity you're chasing could be built into variable defaults and as and when those defaults are made user-configurable, it makes the tool more generally useful. (I also note that in the most general case, it's not hard to imagine simple "meta" config file that might override defaults at the ou-container-builder top-level, eg a user setting the org name for all containers they create. Being able to set the global default, and also use local ContainerConfig.yaml files to override specifics, makes for most generality.

[mmh352]

I see your point with regards to during the dev process. I'll think about adding some kind of --dev flag and how that would fit into the workflow.

Yes, these things could be added and made optional, but then I would have to maintain and test those optional code paths. When somebody comes along with a concrete use-case that requires this (and that cannot simply be satisfied by creating their own tag in a post-processing step), then I will look at how to integrate that and add the required code paths.