Copy environment #163
Copy environment #163
Conversation
…vior to continue - Add back missing Slurm environment setting - Implement environment persistence for LSF, PBSPro, Torque and Grid Engine I also noticed that multiple adapters when dealing with the contents of Script#job_environment explicitly stringify both the keys and the values; this is redundent as that mutation is performed in the Script constructor. Job submission always requires a Script object, which are immutable, and so the adapter-specific stringification sections in the code are safe to remove.
|
Do we also need to populate the environment? That is, we call some open3 api with an environment hash, in lsf it's So my question is, if someone sets this flag is it sufficient to just populate the command, or do we actually need to env variables to this hash so they get passed into open3.capture3's env? |
|
I believe in every case the environment is being passed to the |
|
I think I found the answer from the open3 and process docs, I think that env is additive to the current ENV, not an out right replacement, so I think I answered my own question in that we only need to modify |
|
Are you aware of the ramifications of having both |
|
I am not; I have not yet tested them on live systems yet. That's one of the reasons why I am updating |
|
No I am not. |
|
I am going to test GridEngine and PBSPro tomorrow once I work through some Vagrant issues. |
|
GridEngine and PBSPro both behave as I would expect. # Given a job.sh that echos its environment
A_ENV=value qsub job.sh # Does not output A_ENV
A_ENV=value qsub -V job.sh # Does output A_ENV
A_ENV=value qsub -v B_ENV=something_else job.sh # Outputs B_ENV, but not A_ENV
A_ENV=value qsub -V -v B_ENV=something_else job.sh # Outputs A_ENV and B_ENV |
Fixes #158.