Samuel Lampa

Via some of the articles [here](https://github.com/ardanlabs/gotraining/tree/master/reading#interfaces-and-composition), especially the ones by Will, I have came to realize struct types are another area where we could improve things. So I'll use this...

Well, another option is to encourage people to vendor scipipe as much as possible. Thus locking to a specific version whenver needed. Keeping updates in sync could then be done...

This is on its way now, as I just managed to [start k8s jobs](https://github.com/samuell/k8s-experiments/blob/master/k8sexp.go) via the go api.

Plan of attack: - [ ] Change `SciTask.CustomExecute` to `SciTask.ExecMode`, (with values like `SciTask.ExecModeLocal`, `SciTask.ExecModeHPC`, `SciTask.ExecModeK8s`).

No. Either use [custom executors](https://github.com/scipipe/scipipe/issues/38#issuecomment-362442919), or create totally separate repo, `scipipe-k8s`, that is based off of the BaseProces in scipipe, but wraps that with kubernetes running functionality.

Well, we also have: - [(Almost) ranging over multiple Go channels simultaneously](http://bionics.it/posts/range-over-multiple-go-channels) - The suggestion in #45: > Use the same IP (at least the same interface) for both files...

So, effectively a kind of `GROUPBY` function, right?

Hi @valentin-krasontovitsch , thanks for checking out scipipe. What we are doing right now, while pondering the best way to add proper SLURM support, is to just use the prepend...

Ah, but yes, you should be able to call Go/SLURM library code from within your [custom Go-functions](http://scipipe.org/howtos/golang_components/), for sure, yes!

Otherwise, I'm right now looking hard into introducing a bit more of modularity / pluggability in the code, so that it would be easier for anyone to add custom "runners",...