sci-f/apps

Modular application recipes for the Scientific Filesystem (SCIF)

apps's Issues

add operating system / architecture to tags

add all (current) apps to repo

if lazy loading of robots is needed

https://css-tricks.com/lozad-js-performant-lazy-loading-images/

app submission: should we require including a recipe with header?

If not, we would want to test that the app builds in CI by using the tag to get the OS, and then building via extraction of the content in the markdown file.

Missing cowsay.scif

Hi,
I'm trying to learn using docker and following the examples, but https://github.com/sci-f/sci-f.github.io/blob/master/_posts/tutorials/cowsay.scif is missing.

add support for asciinemas

Need to make generator page

using recipes from local storage!

Suggestions re modularity and multiple entry points for same image

I have been doing a bit with Singularity for the past year, but like the Sci-F %app* stuff in 2.4

I am currently looking to upgrade a keras/theano/tensorflow container image for my users using these features, but there are some aspects which do not seem to quite fit with the paradigm that is discussed in docs that I have read, which seem to stress workflow more than modularity. I am willing to submit the resultant image to shub, but to do so it would be good to adhere to community standards.

Basically, I install some useful libs, python 2 and 3, and then python packages for each of keras, theano, and tensorflow for each python version. (And eventually want to add cuda/nocuda options as well, but for now assume no cuda). All three of the main packages (keras/theano/tensorflow) are
primarily just python modules (although one or two have an auxilliary command), and keras can
be called with an environmental variable to specify whether it should use theano or tensorflow as
a backend.

My "modular install" approach would have %appinstall, etc. entries for
python2
python3
theano-py2
tensorflow-py2
keras-py2
theano-py3
tensorflow-py3
keras-py3

However, this seems overkill from the "workflow" paradigm, since from workflow perspective basically
there are only python2 and python3, plus entry points for the theano/tensorflow backends of keras.

If I do something to do both modularity and workflow, there become so many entry points that it would seem to lose some of the Sci-F design goals.

Any advice?

Make page to submit new app

can it do a PR directly to Github?

add option (encouragement) for user to add labels / maintainer to container recipe

add search across site based on category / tag

add nextflow example

make code snippets copy / pastable

Make instructions for adding content, and API

and do we need tests?

update examples to use SCIF_ namespace

to make the organization format more extendable, we've edited it to have a SCIF_ prefix (and not just be for singularity) so all examples need to be updated here (and with respective repos)

Replace containers-ftw with sci-f in all URLs

There are a number of links pointing to https://containers-ftw.github.io which no longer work. I assume the main URL was changed at some point, and a few places were missed.

For example on the masthead of the GitHub repo:

And in the generated index.json file for the apps API (https://sci-f.github.io/apps/api/index.json):

Searching for "containers-ftw" in the organization shows following occurrences in code:

https://github.com/search?q=org%3Asci-f+%22containers-ftw%22&type=Code

I'm happy to help fix this, and creating this issue so I don't forget.

make views to see filter for specific tag or category

font on apps page for date is unreadable

Work on apps pages:

• apps shouldn't require images, etc, but if present, should show in header
• tags better rendered
• link to code on Github
• better / cleaner buttons to add to recipe, etc.

use local storage to allow user to save collection of apps and render finished singularity recipe