conda-forge / singularity-feedstock Goto Github PK

See common-workflow-language/cwltool#1332 (comment)

To fix this, pull the git tags or set the VERSION environment variable before building

Additional comment:

No response

Thinking that it would be good for us to publish 2.5.0-rc1 as it was released recently. We can publish it under the rc label so people don't get it without opting in. Was able to build it fine locally and can submit a PR. Wanted to see if that was of interest first though.

Now that we are up to speed with the latest, how do we feel about trying to add support for MacOS and possibly M1? I haven't had luck even installing Singularity on my M1, so I think this won't actually succeed, but just throwing it out there...

Really appreciate the work to make Singularity installable in a Conda environment! I use Singularity/Conda/Snakemake together a fair bit in my work, and would love to take advantage of some of the new versions of Singularity (stable at 3.8.4, though they recently released 3.9.0rc2). Are there any plans to move towards theses versions with the Conda feedstock? If not, I use this enough that I'd be happy to take up some of the maintenance burden, as long as I could get a few pointers on what I need to do!

Thanks for the great work!

@conda-forge/singularity

https://apptainer.org/news/community-announcement-20211130

• we will have to rename likely soon or start over (conda-forge/staged-recipes#17160)
• i have a staged recipe singulairty-ce (conda-forge/staged-recipes#17084)
• stay tuned for more info as it becomes available?

• I read the conda-forge documentation and could not find the solution for my problem there.

Issue:

$ conda list

$ conda info

Additional comment:

No response

Given these two editions are diverging, and given that HPC admins will likely buy into the commercialized editions (i.e. CE or PRO), I wonder if it makes more sense for us to maintain both Singularity and SingularityCE here. I doubt the differences are going to be big anytime soon, but it is much easier for us to follow their divergence now (see pr #43).

Three options:

1. Add new branch with singularity-ce (see https://conda-forge.org/docs/maintainer/updating_pkgs.html#maintaining-several-versions) and starting naming them differently (e.g. we will have singularity 3.9.0 and singularity-ce 3.9.0 out of this feedstock)
2. Do a split recipe here.
3. Start a new standalone feedstock for singularity-ce (see here: conda-forge/staged-recipes#17030)

Either way, we need to clean up our current meta.yaml to correctly reference the upstream repos and docs.

@chrisburr, any thoughts?

As of Singularity 3.0.0, we will need to switch the build to use Go as it has been totally rewritten in Go. Leaving this here as a note so that we remember to do this. Also may be good to try building the alpha just to see what issues come up.

• revise all mentions of hpcng vs sylabs to be consistent throughout
• consider starting a separate feedstock: singularity-ce-feedstock as the two offerings (singularity vis-a-vis singularityCE) diverge
• or consider adding two pkgs to be built here (two folders) (is this okay in general for feedstocks? We can do split output instead...)

Additional comment:

No response

On amd64 architecture and v3.8.4 (hf1ae047_1) with squashfs-tools v4.4 (h6b73730_2)
this works

singularity build --sandbox lolcow docker://godlovedc/lolcow

but this fails with unsquashfs not found

singularity pull docker://godlovedc/lolcow
singularity build --sandbox lolcow lolcow_latest.sif

Probably apptainer/singularity#6224
How can I use this feedstock to build the new upstream version?

Changes in singularity 3.6.4 make the relocation patch fundamentally break the relocation patch used by conda-forge.

See apptainer/singularity#5454 (comment) for details.