@akesandgren Via --job-deps-type, you can now specify what type of dependency must be used.

The default depends on the job backend (to retain backward compatibility): --job-deps-type=always_run is the default for PbsPython (equivalent with using afterany deps), while --jobs-deps-type=abort_on_error is the default for both GC3Pie and the new PySlurm job backend.

@akesandgren I hope to add some tests for the PySlurm backend as well...

Any chance that you can give this a spin yourself to see if --job-backend=PySlurm --job works for you?

create_job in parallelbuild sets up easybuild_vars to contain only
PYTHONPATH, MODULEPATH and all variables starting with EASYBUILD
That won't fly... it should not touch the environment at all really (in my opinion at least).
One needs to be able to give it all sorts of env, like SBATCH_ACCOUNT, and a bunch of other slurm realted things, and other EB unrelated things.

@akesandgren That's orthogonal to this PR I think, see the discussion in #2632

There is something wrong.
--job-max-walltime=3 doesn't get passed down into pyslurm in the way it wants.
I get this back (when bypassing the account problem)
python2: error: must supply a time (-t ..)

SlurmJob was passing the wrong parameter to pyslurm. It expects 'time_limit' and not 'time' and it expects an integer in minutes.
I'll try to whip up a PR of the things i can figure out.

@akesandgren I've just pushed support for using Slurm as a job backend, which doesn't require PySlurm at all; it basically just calls sbatch rather than the equivalent method provided by PySlurm.

I'm wondering this is a better way forward: doesn't require having PySlurm as a dependency, and it probably integrates better with site policies since it doesn't talk directly to the SLURM API...

There needs to be a config option for choosing what to put in "#!/bin/sh" of the submit script. We require /bin/bash for things to work. But it seems that is done by sbatch itself...
Might be better to write an actual submit file to use instead of wrap....

Not sure that is the problem i ran into now or not though.

Nah, that wasn't the poroblem. Ignore this comment.

With my latest PR to this one I can get stuff running.
(Although it failed since i was doing --from-pr and the submitted jobs of course didn't have my OAuth token ...)

Will try something local later this evening.

@boegel Anything else you plan on doing with this?

@akesandgren @migueldiascosta is testing this too, doesn't hurt to get some more feedback on it.

But it's good to go imho.

@akesandgren docs update @ easybuilders/easybuild#467