sapporo-wes/sapporo-service

A standard implementation conforming to the Global Alliance for Genomics and Health (GA4GH) Workflow Execution Service (WES) API specification.

sapporo-service's Issues

The issue when accessing API (/service-info)

I deployed sapporo-service with Docker Desktop for Windows, see below:

The status of sapporo-service is running and everything looks fine.

As I referenced SwaggerUI - sapporo-wes - GetExecutableWorkflows, I tried different APIs.

However, http://127.0.0.1:1122/service-info cannot be accessed, http://127.0.0.1:1122/executable-workflows can be accessible, look below:

So how to solve this issue?

2.0.1 installation fails

using pip 20.3.3 from Python3.9:

sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) unable to open database file
(Background on this error at: https://sqlalche.me/e/20/e3q8)

Doesn't display service add error

Nextflow core/GitHub-URL runner

Want to add a runner to run.sh that will checkout the GitHub repository using GitHub-URL and run workflows.

Modify API-definision

• status code
• description

nextflow docker container does not have conda inside

what?

then I had to create this one
https://github.com/inutano/docker-nextflow-with-conda

perhaps we can replace the current one in run.sh

WES 1.1.0 `worfklow_engine`

Now that WES 1.1.0 is out and has workflow_engine could workflow_engine_name be removed or just update to allow client to use workflow_engine which is the same as sapporo's customized workflow_engine_name.

https://ga4gh.github.io/workflow-execution-service-schemas/docs/

SAPPORO-service's Logger Bug

• When accessing GET /runs

sapporo CLI cannot correctly find --run-sh path given relative path from current dir

Ex)

sapporo --host 0.0.0.0 --service-info sapporo/service-info.json --executable-workflows sapporo/executable_workflows.json --run-sh sapporo/run.sh --debug      

wouldn't work in latest version: 1.1.0
used to work for 1.0.14

Automatically discover the workflow engine versions?

Hi!

I just solved an installation issue on my environment*, and now I have Sapporo Service and Sapporo Web running locally on my terminals, and I think I should be able to debug it too (that's how I normally get started with tools :)

The first thing I noticed was that Sapporo showed Toil and Nextflow in my test service, even though I don't have these installed in my Python virtual environment, nor on my local environment.

I think it would be useful if there was a way to specify manually what were the workflow engines, but also to automatically discover each engine (e.g. check if it can import some Python module, or locate an executable on $PATH.)

Thanks!
Bruno

*I was using miniconda, and apparently uwsgi cannot find libpython. I reverted to using Ubuntu's default Python, with a venv after installing python-dev for my Python version 👍 in case someone else has a similar issue.

Use Nextflow

Singularity support

No idea...

Clean up the contents of `run_dir`

There is a need to periodically clean up the contents of run_dir.

• Add a script to clean up with cron
• Every time a post request comes in, check and clean up

Public sapporo-service server

Currently, sapporo-service is not hosted anywhere.
If we want to try sapporo-web, it's not convenient.
It would be nice to have a public sapporo-service server somewhere, although the data is not persistent.

Use WDL