Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A question about output files #157

Open
jschultz opened this issue Nov 13, 2016 · 4 comments
Open

A question about output files #157

jschultz opened this issue Nov 13, 2016 · 4 comments

Comments

@jschultz
Copy link

Hello,

I'm not sure if this is the right place to be asking but since I can't find any discussion forums, here goes.

I'll start by saying that I have found wooey totally brilliant. As I was already using argparse I found it literally worked out of the box (with one single exception, described below). I have set it up to run some real (if still rather experimental) scripts on my VPS here: http://wooey.barraqda.org/ where it seems to work perfectly.

So here are my questions: first, can the handling of output files be configured? I noticed that if my script creates a file without specifying a path, wooey finds the file and makes it available for download in three versions: a straight file and a zip and tar/gzip compressed version. But I also saw from the cat fetcher demo (and tried it myself) that if I create an image file it automagically appears for download with a thumbnail image. So what I would like to do is have a bit more control over this - for example configure which file types appear automagically, what directories are searched for output files, how thumbnails are generated, and which compression types are used. Second, to keep my scripts identical between the wooey and command-line versions, is there some way for the script to detect whether it is running from wooey so that it can adapt to the small differences in running environment?

Many thanks,
Jonathan

@Chris7
Copy link
Member

Chris7 commented Nov 15, 2016

Hi @jschultz,

Glad everything is working out well! So here is how wooey handles output --
A script runs in a created directory, which after the script runs everything in there is then tarred/zipped up and the files are also stored as individual files. Some filetypes it tries to introspect for some common image formats.

I'm not sure atm exactly how much flexibility this will offer you, but you can override these templates for the existing image types (fasta.html, image.html, tabular.html) or add logic to customize how you are rendering the images. The bad news is there is not currently a configuration panel to toggle these options, though I think it might be useful to allow users to disable some views. Also, there is no ability to add custom logic for new filetypes -- though I would love to see that added.

For your scripts, you can actually use the command line to add/update your scripts on wooey. You may pass the --update flag to manage.py addscripts to keep your settings in sync.

Currently, my time is a little sparse so I cannot start on these things, but I'll certainly earmark them for when I have some of that elusive free time and inspiration (would also be more than willing to guide/review PRs).

Chris

@Chris7
Copy link
Member

Chris7 commented Nov 15, 2016

Sorry if it wasn't clear -- but you want to override wooey/preview/image.html to customize that output (and likely look at the existing file to see what is going on).

@jschultz
Copy link
Author

OK thanks for that. I need to find some time to experiment but that should be enough to go on.

One follow-up question - since it appears necessary to strip the directory from any output file names when running under wooey, but this is not suitable for running in other environments, is there a reliable way for a script to determine whether or not it is running under wooey?

@Chris7
Copy link
Member

Chris7 commented Apr 23, 2018

Apologies for the very very late reply, but you can use an environment variable of your choice to indicate it is running in Wooey. Just set a flag on whatever environment is running your workers and check for it in a script.

@Chris7 Chris7 closed this as completed Apr 23, 2018
@Chris7 Chris7 reopened this Apr 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants