Gitpod

[FloWuenne]

This PR adds a config file for gitpod, which will allow to start a Gitpod instance from the spatialdata container. Currently, this is pointing to a test placeholder container I made in my Dockerhub.

To do:

• [ ] Update docker container to CLI container that will get build by Github action, instead of Dockerhub placeholder

[codecov[bot]]

Codecov Report

Merging #326 (9cfa18c) into main (46fa478) will not change coverage. The diff coverage is n/a.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #326   +/-   ##
=======================================
  Coverage   90.61%   90.61%           
=======================================
  Files          36       36           
  Lines        4700     4700           
=======================================
  Hits         4259     4259           
  Misses        441      441           

[FloWuenne]

@LucaMarconato @giovp I am just coming back to this while going over my open PRs. What is your current strategy for containerization of spatialdata packages? If I can give my personal opinion, I think two things would make sense:

1. For a gitpod image to work in the spatialdata ecosystem, it would make sense to create a container that has all of the spatialdata packages installed and ready to use (spatialdata, spatialdata-io, spatialdata-plot).

2. For pipeline languages such as Nextflow, Snakemake and others, I think it would be great to have one container per tool. This could either be done via Dockerfile in each repo and hosting on github container registry within the repo or dockerhub. The other option is adding each tool as a package to bioconda (which then provides a biocontainer automatically at quay.io). If you are open to adding the tools to bioconda, I can help with this, but it is fairly straightforward if it is already on pip (which all spatialdata packages are right?).

[LucaMarconato]

Thanks @flowuenne for getting back on this. I agree with you that the most flexible approach would be to provide a container with all the packages and a container per repo. I think hosting the container in dockerhub could be the way to go since we have now a scverse dockerhub: https://hub.docker.com/u/scverse, and so in this way we can keep the current conda-forge setup from @goanpeca (re conda-forge vs bioconda we could continue the discussion here https://github.com/scverse/spatialdata/issues/403#issuecomment-1879800108).

Currently we don't have time because we are working on some large PRs required for making a new release (in particular for having multi-table support). If you have time to work on this please go ahead, it would be fantastic!

[FloWuenne]

I will see if I can fit this in whenever I have a moment to work on something @LucaMarconato ! For spatialdata I see that I actually already added a docker container, so basically all thats left is the gitub action. When do you want to push containers? Only on release with the release tag? Or whenever there is a merge into main?

[LucaMarconato]

Thank you! For the "per-repository containers" I would do it per release and maybe also for each merge to main to have a "latest" container.

For the container with all the packages from the ecosystem I think I would either rebuild everything for each release, either have a daily job (checking for hashes/versions to see if something changes?).

[FloWuenne]

Sounds good! I can make a PR with a .gitpod action that can do the per repository releases soon and I can also make a github action that builds a container daily. I have something like this for one of my repositories. Might take a week or two depending on when I have time though!

@LucaMarconato you just need to make sure that the Dockerhub Token and credentials are set for this repository, so that it has permissions to push to dockerhub when you merge the PR 😉 !

[LucaMarconato]

Thanks a lot @FloWuenne, that sounds fantastic! Yes I will set up Dockerhub.