Matthieu Muffato

I can see that both containers are under your institute's account, so it looks like you built those two images. As a workaround, @JossWhittle , would you be able to...

Thanks @vsoch , for your https://github.com/singularityhub/singularity-hpc/issues/501#issuecomment-1057704119 . That made me realise that regenerating the modules can't be distinguished from upgrading them, esp. as `shpc` ships the default registry. A new...

Thank you for your analysis, @vsoch I personally value the reproducibility aspect quite a lot, incl. having explicit versions and hashes in `container.yml`. For instance, I would be maintaining my...

Thanks. FYI I'm trying to run binoc locally (cf https://github.com/autamus/binoc/issues/18) and will get back to you once I understand how it can work in practice.

My original request was about regenerating the wrapper scripts upon changes in the shpc codebase, not in the container.yaml themselves – which will now happen more regularly as the registry...

Thinking more about that: I wanted an option to regenerate all modules, wrapper scripts, etc, for existing containers. But that's not reliably tractable anymore since the container.yaml can now be...

Yes, partly. I just pushed a commit that introduces a couple of tests in `test_wrappers.py`

Hi @vsoch . Ours is on an internal GitLab, but essentially it's just a registry without the CI to build `library.json`

> The specific way we implement this is by having 2 Singularity modules, a "singularity" one (MPICH), and a "singularity-openmpi" one. Hi @marcodelapierre . I'm curious about something. Have you...

As far as I could see, it'd be fine limiting all `quay.io/biocointainers` recipes to the content of `/usr/local/bin/`. I don't think there's anything in `/usr/bin` or `/usr/sbin` that's worth exposing