When exploring how to call the Fractal tasks core tasks through Galaxy, the conda distribution has become relevant (so great that we kept maintaining this! :) ). What we would actually need though are entry points to the different task init/compute executables. Instead of doing:
/data/app/Tasks/1/fractal-tasks-core/1.5.0a2/venv/bin/python /data/app/Tasks/1/fractal-tasks-core/1.5.0a2/venv/lib/python3.12/site-packages/fractal_tasks_core/tasks/cellvoyager_to_ome_zarr_init.py
We'd want to do something like:
. /data/app/Tasks/1/fractal-tasks-core/1.5.0a2/venv/bin/activate
cellvoyager_to_ome_zarr_init
We'd do this by exposing the tasks for the CLI by adding something to the pyproject.toml like:
[project.scripts]
cellvoyager-to-ome-zarr-init = "fractal_tasks_core.tasks.cellvoyager_to_ome_zarr_init"
This would greatly simplify how the tasks can be used from the CLI by users or other workflow managers. If it works well, we could look into whether that's a pattern we also establish in the template package and how we'd make it easy to maintain that.
(obviously not a 1.5.0 priority, just creating this issue to track this useful idea from the hackathon)
When exploring how to call the Fractal tasks core tasks through Galaxy, the conda distribution has become relevant (so great that we kept maintaining this! :) ). What we would actually need though are entry points to the different task init/compute executables. Instead of doing:
We'd want to do something like:
We'd do this by exposing the tasks for the CLI by adding something to the pyproject.toml like:
This would greatly simplify how the tasks can be used from the CLI by users or other workflow managers. If it works well, we could look into whether that's a pattern we also establish in the template package and how we'd make it easy to maintain that.
(obviously not a 1.5.0 priority, just creating this issue to track this useful idea from the hackathon)