Minimal dependency installation

[effigies]

Summary

When using tedana as a library and not generating reports, it seems excessive to have bokeh and jinja2 added to the dependency graph. I wonder if there's a way to have a lightweight dependency without sacrificing the user experience you already have.

Additional Detail

One approach could be to create a separate package tedana-core that has the minimum dependencies needed to actually run the numeric processing the tedana provides. Now that you're moving to hatchling as a backend, it's more plausible to have a monorepo containing multiple packages, which would allow something like:

tedana-core/pyproject.toml

[project]
dependencies = [
  "scipy>=1.2.0",
  "scikit-learn>=0.21",
  "nibabel>=2.5.1",
  "nilearn>=0.7",
]

[project.optional-dependencies]
pca = [
    "mapca>=0.0.3"
]

tedana/pyproject.toml

[project]
dependencies = [
  "tedana-core[pca]",
  "matplotlib",
  ...
]

I'm making things up, as I don't know your what components need which dependencies, but would there be any interest in breaking things down in this way?

Next Steps

If you do want to go down this route, I'd be interested in taking a stab at it. I haven't really done the monorepo thing. Can't really promise a timeline, though.

[handwerkerd]

I'm ok with this idea in theory, but it would require a bit of discussion on what is or isn't core. I think, if someone is running tedana denoising with ICA and then component selection, the report is and should be a mandatory output. Especially when tedana is used in a larger pipeline, it is essential to save a visualization that makes it easy for a user to see if something has gone wrong. That would keep bokeh and jinja2 in the core. (Jinja2 has caused some headaches and I love a lighter-weight alternative, but that's beyond me)

The current core function that wouldn't need the reports is generating the t2star map and the optimally combined volumes. The underlying math for those steps are simple enough that, if someone really wants them to be lightweight, it would be easier to just re-code / copy code.

The real thing that could become "core" is our whole framework for taking components (ICA or any time of components), calculating metrics, and classifying components based on those metrics. That has a potential for wider uses and doesn't interantly require multi-echo data. If they were the core of tedana, others could leverage the same code, but there's a bit of a chicken & egg issue in that I'm not sure it's worth really making them a lightweight core until others express interest in using them & others probably won't have interest until we separate them.

If you are interested & decided you have time to try, I'm definitely interested in talking more about this.