Proposal: Replace the putting it all in a container with making a Github repo with Website.

[mahesh-panchal]

I'm really against suggesting using containers as an analysis archive, i.e. packaging the entire analysis in a container. This only works if you run locally. It doesn't work if you want to run with any other tool that is not installed inside the container, e.g. a different job submission system. Often, the issue with reproducibility is that the person wants to reproduce the results on a different compute environment.

I think the time would be better spent teaching how to make a website to present their work. I suggest having an exercise to make a website with quarto and linking it to the code in the repo. The purpose, in particular, is to work on documentation. The repository should have a README and direct to the website. A website isn't necessary but will likely lead to better engagement so showing how to make a basic website might be useful over just showing how to write a well documented README.

[fasterius]

While I agree with you in principle, there are some additional things that needs discussing. There are still people packaging whole studies inside containers (and is thus something they might find in the real world), and we have found (and still do) that this type of thinking is a very common way of thinking when it comes to containers in general, especially for people new to the concept. The question is whether these points (and others I'm missing?) are worth it for keeping that material in.

Like I said, I think that containers should generally only contain the environment and nothing else. The material on packaging the case study has been around since the workshop's beginnings, and re-evaluating it might be in order.

Regarding making a website, I'd say that's a different questions not fully related to the have-or-have-not of packaged containers.

[mahesh-panchal]

While it may be a potentially common way of thinking, then I think that is a failure on us to correct it if people continue to adopt it. I don't think we should be promoting ways of sharing material that actually hinder the execution of the project on alternate systems. The intended way of using those containers is no different from running a normal program, so I think this could be added as a side note that people do this, but it's not advised because it's difficult to interact with third-party tools not in the container ( slurm, apptainer, etc ).

In my opinion, this point on reproducibility is not just about packaging up the software dependencies with the code. It's also about providing an interface to it to make it easy to port to their systems, and importantly describing how to reproduce it. I think documentation is a fundamental part of this that's missing, and a website is the most user-friendly way of doing this (both for people packaging, and for the people trying to reproduce) .

[fasterius]

After discussions we have decided to alter the packaging part to instead only use containers as environments, while still mentioning that people may package projects into contains, even though we do not recommend this (both in the lecture and the tutorial).

Regarding making a website, we deem this to be out of scope for this course, at least for now.

[mahesh-panchal]

What about at least a Github repo then if not a website? There should still be some form of packaging to allow sharing, and a repository is the most basic that is flexible.

[fasterius]

That's what we're currently generally advising, but given these discussions I think it could be made clearer.