all plugins removed from QIIME 2 2026.4 in M-chip macs when installing q2-SCNIC dependencies

Developer Discussion
1

I'm currently trying to get q2-SCNIC to be compatible with the newer QIIME 2 installs (2026.1 and 2026.4) and back in the plugin library. I've run into issues installing one of q2-SCNIC's dependencies, fastspar, into both 2026.1 and 2026.4 on M-chip macs.

While I was able to figure out fastspar install instructions for 2026.1, when I tried those same instructions in 2026.4, all of the QIIME 2 plugins were removed (see this issue and comments for more detailed information on what was done). We think this happened because the fastspar install downgraded a large number of compiler package versions along with the R version already present in the conda environment.

A note: None of these issues arise when installing fastspar into QIIME 2 2026.4 on linux (ubuntu)

Questions for you guys:

  • Do you have any suggestions on preventing all plugins from being removed from QIIME 2 2026.4 when installing fastspar on M-chip macs?
  • Do you think we will be able to keep q2-SCNIC (and fastspar) compatible with future versions of QIIME 2?

Quick links:

2

Hey @madiapgar,

Thanks for this detailed write-up (both here and on Github)! I did some poking around, and found some additional things to share with you.

I downloaded fastspar 1.0.0 from bioconda and examined the recipe file - it looks like one of the culprits might be gsl. Here's the full recipe file (from the unzipped download, this is under info/index.json):

{
  "arch": "x86_64",
  "build": "h70826f6_6",
  "build_number": 6,
  "depends": [
    "armadillo >=14.2,<15.0a0",
    "armadillo >=7.800.1",
    "gnu-getopt",
    "gsl >=2.7,<2.8.0a0",
    "libcxx >=18",
    "libgfortran 5.*",
    "libgfortran5 >=13.2.0",
    "openblas * *openmp*"
  ],
  "license": "GPLv3",
  "name": "fastspar",
  "platform": "osx",
  "subdir": "osx-64",
  "timestamp": 1733853513693,
  "version": "1.0.0"
}

Typically these kind of compatibility problems will come from dependencies with max pins on them (in this case, gsl is pinned to be no greater than 2.7). Based on the release date for gsl 2.7 and 2.8, it looks like this recipe was created prior to the release of 2.8, so this may not be a real code compatibility issue - just a release/build date issue.

As to why this is only a problem on osx - I found bioconda's recipe for fastspar, which shows the gnu-getopt dependency only enforced for osx (the # [osx] tag indicates this):

When reviewing the recipe for gnu-getopt I don't see any glaring dependencies or pins that are an immediate culprit. But this is likely why you're only running into an issue on osx but not linux.

All of this to say - I think there are a couple of immediate things I'd recommend. One thing you can do is open up a PR under bioconda's recipe files that bumps the build number of fastspar (this will be what actually initiates a rebuild). In the meantime (if it's possible), I would attempt to do any additional development for q2-SCNIC on linux, since fastspar's linux build is compatible with our newest QIIME 2 releases. If you're unsure of how to do this, I created some developer recommendations for constructing a local development environment with Docker here.

Let me know if you have any questions about how to proceed! Happy to provide guidance however I can; the world of dependency compatibility can be a bit of a rabbit hole :rabbit_face: :hole:

3

@lizgehret thank you so much for your speedy response! I'll try bumping the build number of fastspar and see if that helps. One of my computers is linux so I'll fully shift to working on q2-SCNIC there.

I'll keep you updated on what I find :slight_smile: