mlr-org / mlr-org/batchtools

Creating jobs without package dependencies installed on head node

Open
#298 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
R
Stars
184
Forks
53
Avg merge
7d 2h
Merged PRs (30d)
1

Description

I have a use-case where I'd like to be able to create and submit jobs from the head node of a cluster that does not itself have the packages being used by the compute nodes. In this case, it's because the dependencies are a PITA to set up, and so I have built a singularity container for running them. Per https://github.com/HenrikBengtsson/future.batchtools/issues/44, I've put the singularity command in my template file and can submit jobs to be run in the container with batchMap and submitJobs.

However, I run into a problem when defining jobs with batchMap using functions not installed on the head node.

Assume pita_package contains pita_function and can't be installed on the head node. Then a call to batchMap results in

> batchMap(pita_package::pita_function, 1:10)
Error in loadNamespace(x) : there is no package called ‘pita_package’

I've been able to work around this by creating a wrapper function for pita_function. E.g.

> pita_wrapper <- function(...) pita_package::pita_function(...) 
> batchMap(pita_wrapper, 1:10)
Adding 10 jobs ...

I'm adding this issue in part to help anyone runs into this question in the future, and in part to see if it makes sense to implement some sort of lazy evaluation into batchMap and its cousins to avoid the workaround.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the batchMap and related job-definition entry points, along with the template configuration used by submitJobs. Reproduce the failure with a function from a package absent on the head node, then determine whether lazy evaluation can defer package loading to the compute container. Done means jobs can be defined and submitted without that package installed on the head node.

Written by the indexing model from the issue text.

Assessment

Tech stack
r
Domain
distributed-systems, hpc
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.