Take stock of the capsulengine + populse_db 2 merge with mia

[servoz]

I will try to summarise all the issues that are already open because at the moment it is a bit scattered and difficult to deal with ... When a issue will be resumed here, I would indicate here his number (in order to be able to go and consult it if necessary because there is some interesting information in it) and I would close it.

Let's go:

Config used:

• capsul branch on master branch
• mia_process on master branch
• populse_db on 2.0 branch (merged with the master of 13.11.2020 - current version of remotes/origin/2.0)
• populse_mia on populse_db2_capsulengine branch (merged with the master of 13.11.2020 - current version of remotes/origin/populse_db2_capsulengine)
• soma-base on the master branch
• soma-workflow on the master branch
• data coming from populse_mia/data_tests/Philips_files/Data_patient imported to mia thanks to mri_conv (in mia: File > Import): one T1 and one Bold images

Important issues (t)/ remarks (r):

• t1: Smooth brick from mia_processes test.
  • Using the T1 data (alej170316-IRMFonct.+perfusion-2016-03-17083444-0-T13DSENSE-T1TFE-000425.000.nii)
    • Initialisation: 6sec, the empty output is not created but the entry is created in the database (contrary to as indicated yesterday in matlab config is not working in jobs #172 I do not observe today an initialisation duration of 2 mins, maybe a misconfiguration on my station at the lab - I was very disturbed yesterday afternoon ... - to check the next time I will go to the lab)
      -̶ ̶R̶u̶n̶:̶ ̶ ̶n̶o̶t̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶ ̶(̶a̶s̶ ̶d̶e̶s̶c̶r̶i̶b̶e̶d̶ ̶i̶n̶ ̶"̶m̶a̶t̶l̶a̶b̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶s̶ ̶n̶o̶t̶ ̶w̶o̶r̶k̶i̶n̶g̶ ̶i̶n̶ ̶j̶o̶b̶s̶ ̶#̶1̶7̶2̶"̶ ̶a̶n̶d̶ ̶"̶g̶i̶v̶e̶ ̶t̶h̶e̶ ̶s̶y̶s̶.̶p̶a̶t̶h̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶r̶o̶c̶e̶s̶s̶_̶c̶m̶d̶l̶i̶n̶e̶ ̶f̶o̶r̶ ̶d̶e̶v̶ ̶m̶o̶d̶e̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶g̶i̶t̶h̶u̶b̶.̶c̶o̶m̶/̶p̶o̶p̶u̶l̶s̶e̶/̶c̶a̶p̶s̶u̶l̶/̶p̶u̶l̶l̶/̶1̶6̶7̶"̶)̶:̶ ̶s̶t̶d̶o̶u̶t̶ ̶d̶i̶s̶p̶l̶a̶y̶:̶

̶r̶u̶n̶n̶i̶n̶g̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶.̶.̶.̶
̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶s̶t̶a̶r̶t̶i̶n̶g̶ ̶i̶n̶ ̶l̶i̶g̶h̶t̶ ̶m̶o̶d̶e̶
̶W̶o̶r̶k̶f̶l̶o̶w̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶i̶n̶i̶t̶i̶a̶l̶i̶s̶e̶d̶
̶
̶ ̶W̶h̶e̶n̶ ̶t̶h̶e̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶ ̶w̶a̶s̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶,̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶e̶x̶c̶e̶p̶t̶i̶o̶n̶ ̶w̶a̶s̶ ̶r̶a̶i̶s̶e̶d̶:̶ ̶E̶r̶r̶o̶r̶ ̶d̶u̶r̶i̶n̶g̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶.̶ ̶S̶t̶a̶t̶u̶s̶=̶(̶'̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶'̶,̶ ̶1̶,̶ ̶N̶o̶n̶e̶,̶ ̶N̶o̶n̶e̶)̶.̶
̶T̶h̶e̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶h̶a̶s̶ ̶n̶o̶t̶ ̶b̶e̶e̶n̶ ̶r̶e̶m̶o̶v̶e̶d̶ ̶f̶r̶o̶m̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶a̶n̶d̶ ̶m̶u̶s̶t̶ ̶b̶e̶ ̶d̶e̶l̶e̶t̶e̶d̶ ̶m̶a̶n̶u̶a̶l̶l̶y̶.̶ ̶
̶F̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶5̶8̶]̶
̶A̶b̶o̶r̶t̶e̶d̶/̶k̶i̶l̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶]̶
̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶
̶-̶-̶-̶-̶ ̶f̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶ ̶i̶n̶f̶o̶ ̶-̶-̶-̶
̶*̶ ̶j̶o̶b̶:̶ ̶5̶8̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶
̶*̶ ̶e̶x̶i̶t̶ ̶s̶t̶a̶t̶u̶s̶:̶ ̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶
̶*̶ ̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶:̶
̶'̶p̶y̶t̶h̶o̶n̶3̶'̶ ̶'̶-̶c̶'̶ ̶'̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶'̶
̶*̶ ̶e̶x̶i̶t̶ ̶v̶a̶l̶u̶e̶:̶ ̶1̶
̶*̶ ̶t̶e̶r̶m̶ ̶s̶i̶g̶n̶a̶l̶:̶ ̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶e̶n̶v̶ ̶-̶-̶-̶-̶
̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶-̶-̶-̶-̶
̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶s̶p̶m̶1̶2̶-̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶d̶i̶r̶e̶c̶t̶o̶r̶y̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶l̶o̶c̶a̶l̶/̶S̶P̶M̶/̶s̶p̶m̶1̶2̶_̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶v̶e̶r̶s̶i̶o̶n̶'̶:̶ ̶'̶1̶2̶'̶,̶ ̶'̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶:̶ ̶T̶r̶u̶e̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶}̶}̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶o̶u̶t̶ ̶-̶-̶-̶-̶
̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶e̶r̶r̶ ̶-̶-̶-̶-̶
̶T̶r̶a̶c̶e̶b̶a̶c̶k̶ ̶(̶m̶o̶s̶t̶ ̶r̶e̶c̶e̶n̶t̶ ̶c̶a̶l̶l̶ ̶l̶a̶s̶t̶)̶:̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶<̶s̶t̶r̶i̶n̶g̶>̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶,̶ ̶i̶n̶ ̶<̶m̶o̶d̶u̶l̶e̶>̶
̶M̶o̶d̶u̶l̶e̶N̶o̶t̶F̶o̶u̶n̶d̶E̶r̶r̶o̶r̶:̶ ̶N̶o̶ ̶m̶o̶d̶u̶l̶e̶ ̶n̶a̶m̶e̶d̶ ̶'̶c̶a̶p̶s̶u̶l̶'̶
̶ ̶.̶.̶.̶

• r1: With populse_db and populse_mia on master, initialisation take less than a sec. Here also an empty output is not created but the entry is created in the database. I thought we had written code so that there is always an empty output created at the time of initialisation. I'm not very clear on this anymore. To be clarified because it is sure that there is a risk of malfunctioning afterwards ...

[servoz]

̶_̶C̶h̶a̶n̶g̶e̶ ̶o̶f̶ ̶c̶o̶n̶f̶i̶g̶:̶_̶
̶-̶ ̶̶̶c̶a̶p̶s̶u̶l̶ ̶o̶n̶ ̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶ ̶b̶r̶a̶n̶c̶h̶̶̶ ̶(̶m̶e̶r̶g̶e̶d̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶o̶f̶ ̶1̶3̶.̶1̶1̶.̶2̶0̶2̶0̶ ̶-̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶o̶f̶ ̶r̶e̶m̶o̶t̶e̶s̶/̶o̶r̶i̶g̶i̶n̶/̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶)̶
̶-̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶-̶ ̶̶̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶o̶n̶ ̶2̶.̶0̶ ̶b̶r̶a̶n̶c̶h̶̶̶ ̶(̶m̶e̶r̶g̶e̶d̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶o̶f̶ ̶1̶3̶.̶1̶1̶.̶2̶0̶2̶0̶ ̶-̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶o̶f̶ ̶r̶e̶m̶o̶t̶e̶s̶/̶o̶r̶i̶g̶i̶n̶/̶2̶.̶0̶)̶
̶-̶ ̶̶̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶o̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶b̶r̶a̶n̶c̶h̶̶̶ ̶(̶m̶e̶r̶g̶e̶d̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶o̶f̶ ̶1̶3̶.̶1̶1̶.̶2̶0̶2̶0̶ ̶-̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶o̶f̶ ̶r̶e̶m̶o̶t̶e̶s̶/̶o̶r̶i̶g̶i̶n̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶)̶
̶-̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶-̶ ̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶-̶ ̶d̶a̶t̶a̶ ̶c̶o̶m̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶d̶a̶t̶a̶_̶t̶e̶s̶t̶s̶/̶P̶h̶i̶l̶i̶p̶s̶_̶f̶i̶l̶e̶s̶/̶D̶a̶t̶a̶_̶p̶a̶t̶i̶e̶n̶t̶ ̶i̶m̶p̶o̶r̶t̶e̶d̶ ̶t̶o̶ ̶m̶i̶a̶ ̶t̶h̶a̶n̶k̶s̶ ̶t̶o̶ ̶m̶r̶i̶_̶c̶o̶n̶v̶ ̶(̶i̶n̶ ̶m̶i̶a̶:̶ ̶F̶i̶l̶e̶ ̶>̶ ̶I̶m̶p̶o̶r̶t̶)̶:̶ ̶o̶n̶e̶ ̶T̶1̶ ̶a̶n̶d̶ ̶o̶n̶e̶ ̶B̶o̶l̶d̶ ̶i̶m̶a̶g̶e̶s̶
̶
̶̶̶-̶ ̶t̶2̶̶̶:̶ ̶S̶m̶o̶o̶t̶h̶ ̶b̶r̶i̶c̶k̶ ̶f̶r̶o̶m̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶t̶e̶s̶t̶.̶
̶ ̶ ̶ ̶ ̶-̶ ̶U̶s̶i̶n̶g̶ ̶t̶h̶e̶ ̶T̶1̶ ̶d̶a̶t̶a̶ ̶(̶a̶l̶e̶j̶1̶7̶0̶3̶1̶6̶-̶I̶R̶M̶F̶o̶n̶c̶t̶.̶+̶p̶e̶r̶f̶u̶s̶i̶o̶n̶-̶2̶0̶1̶6̶-̶0̶3̶-̶1̶7̶0̶8̶3̶4̶4̶4̶-̶0̶-̶T̶1̶3̶D̶S̶E̶N̶S̶E̶-̶T̶1̶T̶F̶E̶-̶0̶0̶0̶4̶2̶5̶.̶0̶0̶0̶.̶n̶i̶i̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶I̶n̶i̶t̶i̶a̶l̶i̶s̶a̶t̶i̶o̶n̶ ̶a̶s̶ ̶i̶n̶ ̶t̶1̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶R̶u̶n̶:̶ ̶n̶o̶t̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶:̶ ̶s̶t̶d̶o̶u̶t̶ ̶d̶i̶s̶p̶l̶a̶y̶:̶

 ̶r̶u̶n̶n̶i̶n̶g̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶.̶.̶.̶
̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶/̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶/̶c̶l̶i̶e̶n̶t̶_̶t̶y̶p̶e̶s̶.̶p̶y̶:̶3̶0̶7̶:̶ ̶U̶s̶e̶r̶W̶a̶r̶n̶i̶n̶g̶:̶ ̶i̶m̶p̶o̶r̶t̶ ̶s̶y̶s̶;̶ ̶s̶y̶s̶.̶p̶a̶t̶h̶ ̶=̶ ̶[̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶7̶.̶z̶i̶p̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶l̶i̶b̶-̶d̶y̶n̶l̶o̶a̶d̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶c̶i̶k̶i̶t̶_̶i̶m̶a̶g̶e̶-̶0̶.̶1̶5̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶x̶-̶1̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶r̶d̶f̶l̶i̶b̶-̶5̶.̶0̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶p̶-̶5̶.̶0̶.̶1̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶c̶s̶v̶2̶r̶e̶p̶o̶r̶t̶-̶0̶.̶1̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶P̶y̶Q̶t̶5̶-̶5̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶r̶o̶c̶e̶s̶s̶e̶s̶'̶]̶;̶ ̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶ ̶c̶o̶n̶t̶a̶i̶n̶s̶ ̶s̶i̶n̶g̶l̶e̶ ̶q̶u̶o̶t̶e̶.̶ ̶I̶t̶ ̶c̶o̶u̶l̶d̶ ̶f̶a̶i̶l̶ ̶u̶s̶i̶n̶g̶ ̶D̶R̶M̶A̶A̶
̶ ̶ ̶%̶ ̶c̶o̶m̶m̶a̶n̶d̶_̶e̶l̶e̶m̶,̶ ̶U̶s̶e̶r̶W̶a̶r̶n̶i̶n̶g̶)̶
̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶s̶t̶a̶r̶t̶i̶n̶g̶ ̶i̶n̶ ̶l̶i̶g̶h̶t̶ ̶m̶o̶d̶e̶
̶W̶o̶r̶k̶f̶l̶o̶w̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶i̶n̶i̶t̶i̶a̶l̶i̶s̶e̶d̶
̶
̶ ̶W̶h̶e̶n̶ ̶t̶h̶e̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶ ̶w̶a̶s̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶,̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶e̶x̶c̶e̶p̶t̶i̶o̶n̶ ̶w̶a̶s̶ ̶r̶a̶i̶s̶e̶d̶:̶ ̶E̶r̶r̶o̶r̶ ̶d̶u̶r̶i̶n̶g̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶.̶ ̶S̶t̶a̶t̶u̶s̶=̶(̶'̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶'̶,̶ ̶1̶,̶ ̶N̶o̶n̶e̶,̶ ̶N̶o̶n̶e̶)̶.̶
̶T̶h̶e̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶h̶a̶s̶ ̶n̶o̶t̶ ̶b̶e̶e̶n̶ ̶r̶e̶m̶o̶v̶e̶d̶ ̶f̶r̶o̶m̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶a̶n̶d̶ ̶m̶u̶s̶t̶ ̶b̶e̶ ̶d̶e̶l̶e̶t̶e̶d̶ ̶m̶a̶n̶u̶a̶l̶l̶y̶.̶ ̶
̶F̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶5̶6̶]̶
̶A̶b̶o̶r̶t̶e̶d̶/̶k̶i̶l̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶]̶
̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶
̶-̶-̶-̶-̶ ̶f̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶ ̶i̶n̶f̶o̶ ̶-̶-̶-̶
̶*̶ ̶j̶o̶b̶:̶ ̶5̶6̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶
̶*̶ ̶e̶x̶i̶t̶ ̶s̶t̶a̶t̶u̶s̶:̶ ̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶
̶*̶ ̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶:̶
̶'̶p̶y̶t̶h̶o̶n̶3̶'̶ ̶'̶-̶c̶'̶ ̶'̶i̶m̶p̶o̶r̶t̶ ̶s̶y̶s̶;̶ ̶s̶y̶s̶.̶p̶a̶t̶h̶ ̶=̶ ̶[̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶\̶'̶,̶ ̶\̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶7̶.̶z̶i̶p̶\̶'̶,̶ ̶\̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶\̶'̶,̶ ̶\̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶l̶i̶b̶-̶d̶y̶n̶l̶o̶a̶d̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶c̶i̶k̶i̶t̶_̶i̶m̶a̶g̶e̶-̶0̶.̶1̶5̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶x̶-̶1̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶r̶d̶f̶l̶i̶b̶-̶5̶.̶0̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶p̶-̶5̶.̶0̶.̶1̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶c̶s̶v̶2̶r̶e̶p̶o̶r̶t̶-̶0̶.̶1̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶P̶y̶Q̶t̶5̶-̶5̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶\̶'̶,̶ ̶\̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶\̶'̶,̶ ̶\̶'̶/̶u̶s̶r̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶\̶'̶,̶ ̶\̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶r̶o̶c̶e̶s̶s̶e̶s̶\̶'̶]̶;̶ ̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶'̶
̶*̶ ̶e̶x̶i̶t̶ ̶v̶a̶l̶u̶e̶:̶ ̶1̶
̶*̶ ̶t̶e̶r̶m̶ ̶s̶i̶g̶n̶a̶l̶:̶ ̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶e̶n̶v̶ ̶-̶-̶-̶-̶
̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶-̶-̶-̶-̶
̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶s̶p̶m̶1̶2̶-̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶d̶i̶r̶e̶c̶t̶o̶r̶y̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶l̶o̶c̶a̶l̶/̶S̶P̶M̶/̶s̶p̶m̶1̶2̶_̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶v̶e̶r̶s̶i̶o̶n̶'̶:̶ ̶'̶1̶2̶'̶,̶ ̶'̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶:̶ ̶T̶r̶u̶e̶}̶}̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶o̶u̶t̶ ̶-̶-̶-̶-̶
̶
̶C̶h̶a̶n̶g̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶d̶i̶r̶e̶c̶t̶o̶r̶y̶ ̶t̶o̶ ̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶D̶a̶t̶a̶/̶I̶R̶M̶/̶p̶r̶o̶j̶e̶c̶t̶s̶_̶m̶i̶a̶/̶r̶e̶l̶2̶_̶t̶e̶s̶t̶/̶s̶c̶r̶i̶p̶t̶s̶ ̶d̶i̶r̶e̶c̶t̶o̶r̶y̶ ̶.̶.̶.̶
̶
̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶e̶r̶r̶ ̶-̶-̶-̶-̶
̶T̶r̶a̶c̶e̶b̶a̶c̶k̶ ̶(̶m̶o̶s̶t̶ ̶r̶e̶c̶e̶n̶t̶ ̶c̶a̶l̶l̶ ̶l̶a̶s̶t̶)̶:̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶<̶s̶t̶r̶i̶n̶g̶>̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶,̶ ̶i̶n̶ ̶<̶m̶o̶d̶u̶l̶e̶>̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶c̶a̶p̶s̶u̶l̶/̶p̶r̶o̶c̶e̶s̶s̶/̶p̶r̶o̶c̶e̶s̶s̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶7̶1̶0̶,̶ ̶i̶n̶ ̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶
̶ ̶ ̶ ̶ ̶r̶e̶s̶u̶l̶t̶ ̶=̶ ̶c̶e̶.̶s̶t̶u̶d̶y̶_̶c̶o̶n̶f̶i̶g̶.̶r̶u̶n̶(̶p̶r̶o̶c̶e̶s̶s̶,̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶_̶d̶i̶c̶t̶=̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶c̶a̶p̶s̶u̶l̶/̶s̶t̶u̶d̶y̶_̶c̶o̶n̶f̶i̶g̶/̶s̶t̶u̶d̶y̶_̶c̶o̶n̶f̶i̶g̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶4̶2̶8̶,̶ ̶i̶n̶ ̶r̶u̶n̶
̶ ̶ ̶ ̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶_̶d̶i̶c̶t̶=̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶_̶d̶i̶c̶t̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶c̶a̶p̶s̶u̶l̶/̶s̶t̶u̶d̶y̶_̶c̶o̶n̶f̶i̶g̶/̶r̶u̶n̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶5̶8̶,̶ ̶i̶n̶ ̶r̶u̶n̶_̶p̶r̶o̶c̶e̶s̶s̶
̶ ̶ ̶ ̶ ̶r̶e̶t̶u̶r̶n̶c̶o̶d̶e̶ ̶=̶ ̶p̶r̶o̶c̶e̶s̶s̶_̶i̶n̶s̶t̶a̶n̶c̶e̶.̶_̶r̶u̶n̶_̶p̶r̶o̶c̶e̶s̶s̶(̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶r̶o̶c̶e̶s̶s̶_̶m̶i̶a̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶6̶8̶,̶ ̶i̶n̶ ̶_̶r̶u̶n̶_̶p̶r̶o̶c̶e̶s̶s̶
̶ ̶ ̶ ̶ ̶s̶e̶l̶f̶.̶r̶u̶n̶_̶p̶r̶o̶c̶e̶s̶s̶_̶m̶i̶a̶(̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶/̶s̶p̶m̶/̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶6̶8̶7̶,̶ ̶i̶n̶ ̶r̶u̶n̶_̶p̶r̶o̶c̶e̶s̶s̶_̶m̶i̶a̶
̶ ̶ ̶ ̶ ̶s̶e̶l̶f̶.̶p̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶(̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶/̶n̶i̶p̶y̶p̶e̶/̶i̶n̶t̶e̶r̶f̶a̶c̶e̶s̶/̶b̶a̶s̶e̶/̶c̶o̶r̶e̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶4̶1̶9̶,̶ ̶i̶n̶ ̶r̶u̶n̶
̶ ̶ ̶ ̶ ̶r̶u̶n̶t̶i̶m̶e̶ ̶=̶ ̶s̶e̶l̶f̶.̶_̶r̶u̶n̶_̶i̶n̶t̶e̶r̶f̶a̶c̶e̶(̶r̶u̶n̶t̶i̶m̶e̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶/̶n̶i̶p̶y̶p̶e̶/̶i̶n̶t̶e̶r̶f̶a̶c̶e̶s̶/̶s̶p̶m̶/̶b̶a̶s̶e̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶3̶8̶5̶,̶ ̶i̶n̶ ̶_̶r̶u̶n̶_̶i̶n̶t̶e̶r̶f̶a̶c̶e̶
̶ ̶ ̶ ̶ ̶d̶e̶e̶p̶c̶o̶p̶y̶(̶s̶e̶l̶f̶.̶_̶p̶a̶r̶s̶e̶_̶i̶n̶p̶u̶t̶s̶(̶)̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶/̶n̶i̶p̶y̶p̶e̶/̶i̶n̶t̶e̶r̶f̶a̶c̶e̶s̶/̶s̶p̶m̶/̶b̶a̶s̶e̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶5̶9̶6̶,̶ ̶i̶n̶ ̶_̶m̶a̶k̶e̶_̶m̶a̶t̶l̶a̶b̶_̶c̶o̶m̶m̶a̶n̶d̶
̶ ̶ ̶ ̶ ̶{̶s̶e̶l̶f̶.̶j̶o̶b̶n̶a̶m̶e̶:̶ ̶s̶e̶l̶f̶.̶r̶e̶f̶o̶r̶m̶a̶t̶_̶d̶i̶c̶t̶_̶f̶o̶r̶_̶s̶a̶v̶e̶m̶a̶t̶(̶c̶o̶n̶t̶e̶n̶t̶s̶[̶0̶]̶)̶}̶
̶A̶t̶t̶r̶i̶b̶u̶t̶e̶E̶r̶r̶o̶r̶:̶ ̶'̶S̶m̶o̶o̶t̶h̶'̶ ̶o̶b̶j̶e̶c̶t̶ ̶h̶a̶s̶ ̶n̶o̶ ̶a̶t̶t̶r̶i̶b̶u̶t̶e̶ ̶'̶r̶e̶f̶o̶r̶m̶a̶t̶_̶d̶i̶c̶t̶_̶f̶o̶r̶_̶s̶a̶v̶e̶m̶a̶t̶'̶

[denisri]

issues to solve:
#172
populse/capsul#167
later:
populse/capsul#170

Are #172 and populse/capsul#167 still causing problems ? (I have worked on them)

• init is slow (no ticket yet): I maybe have a clue:
  Config() is reinstantiated every time we access it (this means thousands of times). It used to contain just a dict, which is read from a json file. Now it also contains a CapsulEngine and its database storage, which needs to be entirely rebuilt each time the Config object is re-created. Then access to Capsul config goes through database requests, so possibly populse_db2 (without a cache) is slowing down things, but my guess is that avoiding recreating the DB would accelerate things. We should have a single Config object somewhere (or a singleton) in MIA, which would be reused instead of re-created all the time.
  Otherwise the Capsul completion system can take a bit of time, too, but I don't think it is so much here for a Mia/nipype process.

[denisri]

the empty output is not created but the entry is created in the database

Yes, I removed the empty files creation. We can of curse discuss about it. My motivations were that 1) in a distributed execution model, files are not necessarily available locally so there is no point in creating them on the local filesystem, and 2) empty files are not valid, they cannot be used in later processing, thus should ideally not exist: they would introduce much confusion in the database and we would not know the state of the data. If some processes need them to exist, it's probably a bug in them and we may rather fix/patch them instead.
There is still a point however that is wrong in the current state of the branch/PR: data are still registered in the database before process execution and are thus visible in the database whereas they do not exist (yet). So I suggest we do not register them during init, but after pipeline execution. This is all the more important that we do not necessarily execute a pipeline after init, and it's confusing and not normal that data exist in the database when they are not actually created. This raises 2 other points I haven't mentioned yet:

• during init some questions are sometimes asked to the user (and sometimes several times) about inheritance of tags. I admit I don't understand all of it, and I suspect many naive users will also not - and will not wish to bother about them. These should probably be handled automatically by the completion system.

• we have an init function before running a pipeline, but not a post-process function. We maybe should have one to index output data in the database and maybe perform other cleanups after execution ? This would be called automatically in most cases (when the client GUI monitors execution and can detect when execution is finished), and in some cases it would be called "later" after a remote execution if the user disconnects the client: then the post-processing should be done when re-connecting a new client, or maybe manually (?)

[servoz]

As I mentioned at the last meeting, this dogma of creation of empty file at the initialisation time comes from the early work on the mia and I don't remember in detail all the reasons but as far as I can remember, it was mainly because the nipype was asking for these files to exist as input for the next brick in a pipeline. Again this is a bit dated and if I remember correctly this was the main motivation. Today it seems that this constraint was more a bug than a real need. I fully understand and agree with your arguments for not creating the empty files or adding them to the database at the time of initialisation. However as we have integrated this notion (that's why I'm writing dogma at the beginning of this post) from the beginning of our work on mia and mia_processes I find it difficult to evaluate the impact in terms of code changes if we remove this way of doing things. Certainly small for mia, but not negligible for mia_processes. That there is a need to change the codes to be in a more rational functioning is not a valid reason not to do it! I'll just need some time to evaluate what this will entail in terms of code change (I'm looking forward to moving on to higher releases in populse, so this evaluation should be done quickly, say this week). The second little problem I see with not adding data at the time of initialisation is that there are "init "metadata: Done or not Done and "Init time" that are created for the data (in Bricks field). I think this is an interesting piece of information. We should find a way to keep this information and add it at the run time if everything is done at that time. In short, I'm not against it, but we need to think about a few things.
I will come again for your 2 last points .. it's lunch time :-)

[sapetnioc]

To my opinion, there must be two things in the database : - A record of the process with all its parameters stored at init time. This is where the required output file names would be stored (whether they exist or not) - An entry for each data created by the process. This has to be created in the post execution method Denis talked about. I also think we should clearly identify and isolate (possibly in a specific method) initialization steps that may require user interaction. If possible, when a question is asked to the user, the answer should be stored in the configuration. That way, with a properly configured environment, it will always be possible to run pipelines without user interaction.

[servoz]

• concerning the questions that can be asked to the user:
  Given the centrality of the database in mia, it is important that all fields (tags, metadata, etc. - there are several terms for the same thing) are filled in for each data in the database (this bring up the problem of adding by hand a data to the database, i.e. without using mri_conv as input, because in this case all the tags have an empty value, but this is another problem - which we will have to discuss one day, because in release 2, if I understand correctly, there is clearly the possibility of using, via the controller, data browser without using mri_conv. ..). So during initialisation, if there is only one input image (for example a smooth), the output inherits all the tags of the input image. To do this strictly we should modify the tags changed by the brick (example, the tag corresponding to the resolution must be changed to match the smooth done). It's not the case yet, it's something I'll have to do for all the mia_processes bricks but I confess that for the moment I didn't have time to do it, it's not very complicated. On the other hand if there are several inputs (e.g. a co-registration) mia has no way of knowing which image will inherit the output brick. This management is done in the mia_processes bricks which must define the class attribute inheritance_dict which defines exactly which should inherit the output brick or bricks. This is in my opinion the right place to manage inheritance because mia has no way to know what happens in the brick. However, when it comes to bricks not coming from mia_processes this inheritance is not managed. In this case if there are more than two input images there is "uncertainty" and mia opens a popup to ask from which to inherit the output(s) (if i remember well - I only use currently mia_processes bricks - we set a skip option if user don't want to choose ... but it's a bad idea because the tags could be wrong ..). All these questions are really not trivial. If we delete the creation in the database at the initialisation time you will have to do it at the time of the run (or after). Otherwise, I believe that we will produce an interest regression of mia (in my opinion, the innovative feature of mia is the ubiquitous nature of the database with the pipeline manager).

[servoz]

• concerning a post-processing function :
  The idea is appealing. Moreover, if we remove certain features, which we still consider important, during the initialisation, the idea of having a post-processing function will prove to be inevitable.

[denisri]

For tags inheritance, I agree that MIA itself cannot know how to do it in a general way. But a process, or a pipeline, may have this knowledge when it's designed for a specific application (although there are also some generic processes). Thus it should not be the responsibility of the user to decide on that (moreover human users are error-prone, and lazy...). More precisely this information should be brought alongside processes or pipelines, in an optional or maybe context-specific way. And I think Capsul has already a system for that in the completion engine, which (as far as I remember) allows to assign attributes (or tags) to each parameter (input or output ones), then to build filenames for these parameters using the tags.
I'll look at it again because I don't have this part in mind right now, and let you know.

[sapetnioc]

Meta information goes far beyond image characteristics, it can describe the typology of data (it's an image, it's an MR image, it's a 3D T1 image, etc.), the subject of the data (species, identification code, etc.), the acquisition context, etc. To make it simple, it is possible to define a few layers that may produce metadata for an output after a process execution. For instance : 1. The process producing the output 1. The pipeline in which the process is included 1. The execution environment 1. The destination database environment According to my experience with BrainVISA that has handled user defined ontologies for years, I am convinced that all metadata related stuff must be defined separately from the computing part. This is non intuitive because it is highly related to the process itself. But doing this is the only way to handle, in the long run, the variety of existing data organizations as well as their modifications in time. If metadata management is hardcoded in processes, it imposes a de facto ontology on the data that we will never have time to properly define and any change in data organization will be a mess that involves modification on many (if not all) processes. Another topic that we must talk about.

…

On Mon, Nov 16, 2020 at 3:08 PM Eric Condamine ***@***.***> wrote: - concerning the questions that can be asked to the user: Given the centrality of the database in mia, it is important that all fields (tags, metadata, etc. - there are several terms for the same thing) are filled in for each data in the database (this bring up the problem of adding by hand a data to the database, i.e. without using mri_conv as input, because in this case all the tags have an empty value, but this is another problem - which we will have to discuss one day, because in release 2, if I understand correctly, there is clearly the possibility of using, via the controller, data browser without using mri_conv. ..). So during initialisation, if there is only one input image (for example a smooth), the output inherits all the tags of the input image. To do this strictly we should modify the tags changed by the brick (example, the tag corresponding to the resolution must be changed to match the smooth done). It's not the case yet, it's something I'll have to do for all the mia_processes bricks but I confess that for the moment I didn't have time to do it, it's not very complicated. On the other hand if there are several inputs (e.g. a co-registration) mia has no way of knowing which image will inherit the output brick. This management is done in the mia_processes bricks which must define the class attribute inheritance_dict which defines exactly which should inherit the output brick or bricks. This is in my opinion the right place to manage inheritance because mia has no way to know what happens in the brick. However, when it comes to bricks not coming from mia_processes this inheritance is not managed. In this case if there are more than two input images there is "uncertainty" and mia opens a popup to ask from which to inherit the output(s) (if i remember well - I only use currently mia_processes bricks - we set a skip option if user don't want to choose ... but it's a bad idea because the tags could be wrong ..). All these questions are really not trivial. If we delete the creation in the database at the initialisation time you will have to do it at the time of the run (or after). Otherwise, I believe that we will produce an interest regression of mia (in my opinion, the innovative feature of mia is the ubiquitous nature of the database with the pipeline manager). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#180 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXLUTQI5GHJPTKT2FI6LNLSQEW5ZANCNFSM4TUOBY2Q> .

[servoz]

concercing:

A record of the process with all its parameters stored at init time. This
is where the required output file names would be stored (whether they exist
or not)

in fact, unless I'm wrong, this is a bit like what we currently do during initialisation, but not in "process form". Currently during initialisation there is creation in the database of an entry for each output image. As said previously, this entry contains all the tags of the image from which it inherits and the tags modified by the brick (process) should be modified accordingly (remains to be done, easy to do, just lack of time). In addition, there is a special "Bricks" tag which, during initialisation, includes the name of the brick (process). If we click on this brick it gives access to all the input and output parameters of the brick as well as the "init" "init_time" tags etc ... It is a little close to what you describe. The best would be to see in practice that it is better than a description.
On the other hand I do not see how we could have a display with just the process (brick) .. to be continued

[servoz]

For tags inheritance, I agree that MIA itself cannot know how to do it in a general way. But a process, or a pipeline, may have this knowledge when it's designed for a specific application (although there are also some generic processes). Thus it should not be the responsibility of the user to decide on that (moreover human users are error-prone, and lazy...). More precisely this information should be brought alongside processes or pipelines, in an optional or maybe context-specific way. And I think Capsul has already a system for that in the completion engine, which (as far as I remember) allows to assign attributes (or tags) to each parameter (input or output ones), then to build filenames for these parameters using the tags.
I'll look at it again because I don't have this part in mind right now, and let you know.

I completely agree with you it is the responsibility of the process (brick) to manage the inheritance and as I wrote previously this is what is done for the bricks of mia_processes. But as Mia allows to use other bricks than those of mia_processes (i.e nipype) there may be cases where the inheritance is not managed in the brick (process) ... And as said previously, the popup asking to define which image should inherit an output, is triggered only when there are several inputs and the inheritance is not managed in the brick. I do not see how to do otherwise. Otherwise, we would lose the utility of the database which gives access to all a bunch of metadata used for the automatic launch or pipeline.

[servoz]

I'm still putting together the different posts about upgrading to the next version.
This is #169 (see this ticket for details of the discussion).
It's not a major issue, rather a remark on ergonomics (more as "r" rather than "t"):
- r2:

in pipeline manager the little triangles hiding or showing the bricks inside seem to have a different behavior than before (if i am not wrong, before it let see all the bricks by default, now it looks like it's the opposite. Do you have any idea why? (minor remark)

In a nutshell (as described in #169, that I close now to avoid duplicates) Mia already allows in File > Package library manager to select the libraries or sub-libraries that will be visible in the pipeline manager. This allows to simplify a lot the "packages" part in the pipeline manager. From here there are two options. Either all parts are unfolded each time you open mia (old view mode), or they are all folded (new view mode). Everyone will be able to prefer one way or the other. Maybe the intermediate situation would be optimal for everyone: The configuration chosen by the user is saved in mia's preferences (properties/process_config.yml?) so that the user finds his preferred environment at the next start of mia.

[servoz]

New tests:

Field visualised in Data Browser (the number should impact the working time):

• FileName
• 1st row affine transform
• Bricks
• EchoTime
• Exp Type
• Type

I) Test of an atomic process (a brick)

• Test old release:

  • config:

    • capsul branch on master branch
    • mia_process on master branch
    • populse_db on master branch
    • populse_mia on master branch
    • soma-base on the master branch
    • soma-workflow on the master branch
    • data coming from populse_mia/data_tests/Philips_files/Data_patient imported to mia thanks to mri_conv (in mia: File > Import): one T1 and one Bold images

  • Smooth process from mia_processes library (in_files=T1 data):

    • init:
      • execution time: <1s
      • output inheritance of the tags from input data(Data Browser) : OK
      • Bricks Field (Data Browser): smooth1 button creation: OK
        • click on smooth1 button: all the input and output parameters available OK + Init: Done; Init Time: available; Exec: no value; Exec Time: no value.
    • run:
      • execution time: 25s
      • output inheritance of the tags from input data (Data Browser): OK
      • Bricks Field(Data Browser): smooth1 button creation: OK
      • click on smooth1 button: all the input and output parameters available OK + Init: Done; Init Time: available; Exec: Done; Exec Time: available.

̶-̶ ̶T̶e̶s̶t̶ ̶n̶e̶w̶ ̶r̶e̶l̶e̶a̶s̶e̶ ̶(̶c̶a̶p̶s̶u̶l̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶)̶:̶
̶ ̶ ̶ ̶ ̶-̶ ̶c̶o̶n̶f̶i̶g̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶c̶a̶p̶s̶u̶l̶ ̶b̶r̶a̶n̶c̶h̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶o̶n̶ ̶2̶.̶0̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶o̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶d̶a̶t̶a̶ ̶c̶o̶m̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶d̶a̶t̶a̶_̶t̶e̶s̶t̶s̶/̶P̶h̶i̶l̶i̶p̶s̶_̶f̶i̶l̶e̶s̶/̶D̶a̶t̶a̶_̶p̶a̶t̶i̶e̶n̶t̶ ̶i̶m̶p̶o̶r̶t̶e̶d̶ ̶t̶o̶ ̶m̶i̶a̶ ̶t̶h̶a̶n̶k̶s̶ ̶t̶o̶ ̶m̶r̶i̶_̶c̶o̶n̶v̶ ̶(̶i̶n̶ ̶m̶i̶a̶:̶ ̶F̶i̶l̶e̶ ̶>̶ ̶I̶m̶p̶o̶r̶t̶)̶:̶ ̶o̶n̶e̶ ̶T̶1̶ ̶a̶n̶d̶ ̶o̶n̶e̶ ̶B̶o̶l̶d̶ ̶i̶m̶a̶g̶e̶s̶
̶
̶ ̶ ̶ ̶ ̶-̶ ̶S̶m̶o̶o̶t̶h̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶f̶r̶o̶m̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶l̶i̶b̶r̶a̶r̶y̶ ̶(̶i̶n̶_̶f̶i̶l̶e̶s̶=̶T̶1̶ ̶d̶a̶t̶a̶)̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶i̶n̶i̶t̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶:̶ ̶7̶s̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶o̶u̶t̶p̶u̶t̶ ̶i̶n̶h̶e̶r̶i̶t̶a̶n̶c̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶t̶a̶g̶s̶ ̶f̶r̶o̶m̶ ̶i̶n̶p̶u̶t̶ ̶d̶a̶t̶a̶ ̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶O̶K̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶B̶r̶i̶c̶k̶s̶ ̶F̶i̶e̶l̶d̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶ ̶b̶u̶t̶t̶o̶n̶ ̶c̶r̶e̶a̶t̶i̶o̶n̶:̶ ̶O̶K̶
- click on smooth1 button: all the input and output parameters available OK + Init: Done; Init Time: available; Exec: not Done; Exec Time: Available r3 => Wrong.
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶r̶u̶n̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶̶̶=̶>̶ ̶W̶r̶o̶n̶g̶:̶̶̶
̶

̶r̶u̶n̶n̶i̶n̶g̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶.̶.̶.̶
̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶s̶t̶a̶r̶t̶i̶n̶g̶ ̶i̶n̶ ̶l̶i̶g̶h̶t̶ ̶m̶o̶d̶e̶
̶W̶o̶r̶k̶f̶l̶o̶w̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶i̶n̶i̶t̶i̶a̶l̶i̶s̶e̶d̶
̶
̶ ̶W̶h̶e̶n̶ ̶t̶h̶e̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶ ̶w̶a̶s̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶,̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶e̶x̶c̶e̶p̶t̶i̶o̶n̶ ̶w̶a̶s̶ ̶r̶a̶i̶s̶e̶d̶:̶ ̶E̶r̶r̶o̶r̶ ̶d̶u̶r̶i̶n̶g̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶.̶ ̶S̶t̶a̶t̶u̶s̶=̶(̶'̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶'̶,̶ ̶1̶,̶ ̶N̶o̶n̶e̶,̶ ̶N̶o̶n̶e̶)̶.̶
̶T̶h̶e̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶h̶a̶s̶ ̶n̶o̶t̶ ̶b̶e̶e̶n̶ ̶r̶e̶m̶o̶v̶e̶d̶ ̶f̶r̶o̶m̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶a̶n̶d̶ ̶m̶u̶s̶t̶ ̶b̶e̶ ̶d̶e̶l̶e̶t̶e̶d̶ ̶m̶a̶n̶u̶a̶l̶l̶y̶.̶ ̶
̶F̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶9̶8̶]̶
̶A̶b̶o̶r̶t̶e̶d̶/̶k̶i̶l̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶]̶
̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶
̶-̶-̶-̶-̶ ̶f̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶ ̶i̶n̶f̶o̶ ̶-̶-̶-̶
̶*̶ ̶j̶o̶b̶:̶ ̶9̶8̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶
̶*̶ ̶e̶x̶i̶t̶ ̶s̶t̶a̶t̶u̶s̶:̶ ̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶
̶*̶ ̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶:̶
̶'̶p̶y̶t̶h̶o̶n̶3̶'̶ ̶'̶-̶c̶'̶ ̶'̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶'̶
̶*̶ ̶e̶x̶i̶t̶ ̶v̶a̶l̶u̶e̶:̶ ̶1̶
̶*̶ ̶t̶e̶r̶m̶ ̶s̶i̶g̶n̶a̶l̶:̶ ̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶e̶n̶v̶ ̶-̶-̶-̶-̶
̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶-̶-̶-̶-̶
̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶s̶p̶m̶1̶2̶-̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶d̶i̶r̶e̶c̶t̶o̶r̶y̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶l̶o̶c̶a̶l̶/̶S̶P̶M̶/̶s̶p̶m̶1̶2̶_̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶v̶e̶r̶s̶i̶o̶n̶'̶:̶ ̶'̶1̶2̶'̶,̶ ̶'̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶:̶ ̶T̶r̶u̶e̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶}̶}̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶o̶u̶t̶ ̶-̶-̶-̶-̶ ̶
̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶e̶r̶r̶ ̶-̶-̶-̶-̶
̶T̶r̶a̶c̶e̶b̶a̶c̶k̶ ̶(̶m̶o̶s̶t̶ ̶r̶e̶c̶e̶n̶t̶ ̶c̶a̶l̶l̶ ̶l̶a̶s̶t̶)̶:̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶<̶s̶t̶r̶i̶n̶g̶>̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶,̶ ̶i̶n̶ ̶<̶m̶o̶d̶u̶l̶e̶>̶
̶M̶o̶d̶u̶l̶e̶N̶o̶t̶F̶o̶u̶n̶d̶E̶r̶r̶o̶r̶:̶ ̶N̶o̶ ̶m̶o̶d̶u̶l̶e̶ ̶n̶a̶m̶e̶d̶ ̶'̶c̶a̶p̶s̶u̶l̶'̶
̶ ̶.̶.̶.̶

̶̶̶r̶4̶ ̶=̶>̶ ̶T̶h̶e̶ ̶n̶e̶w̶ ̶r̶e̶l̶e̶a̶s̶e̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶y̶e̶t̶ ̶w̶o̶r̶k̶ ̶w̶i̶t̶h̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶.̶ ̶S̶t̶i̶l̶l̶ ̶n̶e̶e̶d̶ ̶o̶f̶ ̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶ ̶b̶r̶a̶n̶c̶h̶.̶ ̶W̶h̶a̶t̶ ̶i̶s̶ ̶p̶l̶a̶n̶e̶d̶ ̶?̶ ̶m̶e̶r̶g̶e̶ ̶o̶f̶ ̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶ ̶(̶P̶R̶)̶ ̶?̶ ̶o̶t̶h̶e̶r̶ ̶o̶p̶t̶i̶o̶n̶s̶ ̶?̶̶̶
̶
̶-̶ ̶T̶e̶s̶t̶ ̶n̶e̶w̶ ̶r̶e̶l̶e̶a̶s̶e̶ ̶(̶c̶a̶p̶s̶u̶l̶ ̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶ ̶b̶r̶a̶n̶c̶h̶)̶:̶
̶ ̶ ̶ ̶ ̶-̶ ̶c̶o̶n̶f̶i̶g̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶c̶a̶p̶s̶u̶l̶ ̶b̶r̶a̶n̶c̶h̶ ̶o̶n̶ ̶4̶P̶R̶1̶6̶5̶o̶n̶M̶I̶A̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶o̶n̶ ̶2̶.̶0̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶o̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶d̶a̶t̶a̶ ̶c̶o̶m̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶d̶a̶t̶a̶_̶t̶e̶s̶t̶s̶/̶P̶h̶i̶l̶i̶p̶s̶_̶f̶i̶l̶e̶s̶/̶D̶a̶t̶a̶_̶p̶a̶t̶i̶e̶n̶t̶ ̶i̶m̶p̶o̶r̶t̶e̶d̶ ̶t̶o̶ ̶m̶i̶a̶ ̶t̶h̶a̶n̶k̶s̶ ̶t̶o̶ ̶m̶r̶i̶_̶c̶o̶n̶v̶ ̶(̶i̶n̶ ̶m̶i̶a̶:̶ ̶F̶i̶l̶e̶ ̶>̶ ̶I̶m̶p̶o̶r̶t̶)̶:̶ ̶o̶n̶e̶ ̶T̶1̶ ̶a̶n̶d̶ ̶o̶n̶e̶ ̶B̶o̶l̶d̶ ̶i̶m̶a̶g̶e̶s̶
̶
̶ ̶ ̶ ̶ ̶-̶ ̶S̶m̶o̶o̶t̶h̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶f̶r̶o̶m̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶l̶i̶b̶r̶a̶r̶y̶ ̶(̶i̶n̶_̶f̶i̶l̶e̶s̶=̶T̶1̶ ̶d̶a̶t̶a̶)̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶i̶n̶i̶t̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶:̶ ̶7̶s̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶o̶u̶t̶p̶u̶t̶ ̶i̶n̶h̶e̶r̶i̶t̶a̶n̶c̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶t̶a̶g̶s̶ ̶f̶r̶o̶m̶ ̶i̶n̶p̶u̶t̶ ̶d̶a̶t̶a̶ ̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶O̶K̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶B̶r̶i̶c̶k̶s̶ ̶F̶i̶e̶l̶d̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶ ̶b̶u̶t̶t̶o̶n̶ ̶c̶r̶e̶a̶t̶i̶o̶n̶:̶ ̶O̶K̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶c̶l̶i̶c̶k̶ ̶o̶n̶ ̶s̶m̶o̶o̶t̶h̶1̶ ̶b̶u̶t̶t̶o̶n̶:̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶i̶n̶p̶u̶t̶ ̶a̶n̶d̶ ̶o̶u̶t̶p̶u̶t̶ ̶p̶a̶r̶a̶m̶e̶t̶e̶r̶s̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶O̶K̶ ̶+̶ ̶I̶n̶i̶t̶:̶ ̶D̶o̶n̶e̶;̶ ̶I̶n̶i̶t̶ ̶T̶i̶m̶e̶:̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶;̶ ̶E̶x̶e̶c̶:̶ ̶n̶o̶t̶ ̶D̶o̶n̶e̶;̶ ̶E̶x̶e̶c̶ ̶T̶i̶m̶e̶:̶ ̶A̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶=̶>̶ ̶W̶r̶o̶n̶g̶ ̶(̶̶̶r̶3̶̶̶)̶.̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶r̶u̶n̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶ ̶t̶i̶m̶e̶:̶ ̶3̶0̶s̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶o̶u̶t̶p̶u̶t̶ ̶i̶n̶h̶e̶r̶i̶t̶a̶n̶c̶e̶ ̶o̶f̶ ̶t̶h̶e̶ ̶t̶a̶g̶s̶ ̶f̶r̶o̶m̶ ̶i̶n̶p̶u̶t̶ ̶d̶a̶t̶a̶ ̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶O̶K̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶B̶r̶i̶c̶k̶s̶ ̶F̶i̶e̶l̶d̶(̶D̶a̶t̶a̶ ̶B̶r̶o̶w̶s̶e̶r̶)̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶ ̶b̶u̶t̶t̶o̶n̶ ̶c̶r̶e̶a̶t̶i̶o̶n̶:̶ ̶O̶K̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶-̶ ̶c̶l̶i̶c̶k̶ ̶o̶n̶ ̶s̶m̶o̶o̶t̶h̶1̶ ̶b̶u̶t̶t̶o̶n̶:̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶i̶n̶p̶u̶t̶ ̶a̶n̶d̶ ̶o̶u̶t̶p̶u̶t̶ ̶p̶a̶r̶a̶m̶e̶t̶e̶r̶s̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶O̶K̶ ̶+̶ ̶I̶n̶i̶t̶:̶ ̶D̶o̶n̶e̶;̶ ̶I̶n̶i̶t̶ ̶T̶i̶m̶e̶:̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶;̶ ̶E̶x̶e̶c̶:̶ ̶D̶o̶n̶e̶;̶ ̶E̶x̶e̶c̶ ̶T̶i̶m̶e̶:̶ ̶a̶v̶a̶i̶l̶a̶b̶l̶e̶ ̶(̶g̶o̶o̶d̶ ̶d̶a̶t̶e̶)̶.̶
̶
̶w̶a̶r̶n̶i̶n̶g̶ ̶i̶n̶ ̶s̶t̶d̶o̶u̶t̶:̶
̶

̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶/̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶/̶c̶l̶i̶e̶n̶t̶_̶t̶y̶p̶e̶s̶.̶p̶y̶:̶3̶0̶7̶:̶ ̶U̶s̶e̶r̶W̶a̶r̶n̶i̶n̶g̶:̶ ̶i̶m̶p̶o̶r̶t̶ ̶s̶y̶s̶;̶ ̶s̶y̶s̶.̶p̶a̶t̶h̶ ̶=̶ ̶[̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶7̶.̶z̶i̶p̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶l̶i̶b̶-̶d̶y̶n̶l̶o̶a̶d̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶c̶i̶k̶i̶t̶_̶i̶m̶a̶g̶e̶-̶0̶.̶1̶5̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶x̶-̶1̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶r̶d̶f̶l̶i̶b̶-̶5̶.̶0̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶s̶i̶p̶-̶5̶.̶0̶.̶1̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶c̶s̶v̶2̶r̶e̶p̶o̶r̶t̶-̶0̶.̶1̶.̶0̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶P̶y̶Q̶t̶5̶-̶5̶.̶1̶4̶.̶0̶-̶p̶y̶3̶.̶7̶-̶l̶i̶n̶u̶x̶-̶x̶8̶6̶_̶6̶4̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶l̶o̶c̶a̶l̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶/̶n̶i̶p̶y̶p̶e̶-̶1̶.̶6̶.̶0̶.̶d̶e̶v̶0̶+̶g̶b̶3̶5̶6̶a̶d̶1̶6̶8̶-̶p̶y̶3̶.̶7̶.̶e̶g̶g̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶6̶4̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶u̶s̶r̶/̶l̶i̶b̶/̶p̶y̶t̶h̶o̶n̶3̶.̶7̶/̶s̶i̶t̶e̶-̶p̶a̶c̶k̶a̶g̶e̶s̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶r̶o̶c̶e̶s̶s̶e̶s̶'̶]̶;̶ ̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶ ̶c̶o̶n̶t̶a̶i̶n̶s̶ ̶s̶i̶n̶g̶l̶e̶ ̶q̶u̶o̶t̶e̶.̶ ̶I̶t̶ ̶c̶o̶u̶l̶d̶ ̶f̶a̶i̶l̶ ̶u̶s̶i̶n̶g̶ ̶D̶R̶M̶A̶A̶
̶ ̶ ̶%̶ ̶c̶o̶m̶m̶a̶n̶d̶_̶e̶l̶e̶m̶,̶ ̶U̶s̶e̶r̶W̶a̶r̶n̶i̶n̶g̶)̶

̶
r4:
It seems that few things are unplugged in populse_db2_capsulengine (at least methods from mia_processes.process_mia.Process_Mia class). I don't mind if there is no loss in features. It is obvious that if a certain class or method was coded that there was a reason. If the reason is bad or no longer current: ok. Otherwise it can cause problems. Just one example: in the past, we observed the messages:

Changing from /data/Git_Projects/populse_mia/python/populse_mia directory to /home/econdami/Data/IRM/projects_mia/test/scripts directory ...

Changing from /data/IRM/projects_mia/test/scripts directory to /data/Git_Projects/populse_mia/python/populse_mia directory ...

in the stdout for each brick at the time of the run.
This was to indicate that the pwd is changed for write the matlab script (in the case of a spm brick) and then return to the current pwd. Now there is no more this message. It doesn't bother me too much since the script is well recorded in /home/econdami/Data/IRM/projects_mia/test/scripts (in the example above) but it indicates that things are unplugged. It is hard to know if there will be a loss of functionality as a result of these disconnections ... I will keep going the tests in this direction.

[denisri]

̶J̶o̶b̶ ̶e̶r̶r̶o̶r̶ ̶r̶e̶p̶o̶r̶t̶e̶d̶ ̶a̶b̶o̶v̶e̶:̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶w̶r̶o̶n̶g̶ ̶i̶n̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶:̶

̶-̶-̶-̶-̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶-̶-̶-̶-̶
̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶s̶p̶m̶1̶2̶-̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶d̶i̶r̶e̶c̶t̶o̶r̶y̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶l̶o̶c̶a̶l̶/̶S̶P̶M̶/̶s̶p̶m̶1̶2̶_̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶v̶e̶r̶s̶i̶o̶n̶'̶:̶ ̶'̶1̶2̶'̶,̶ ̶'̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶:̶ ̶T̶r̶u̶e̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶}̶}̶

̶P̶y̶t̶h̶o̶n̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶s̶ ̶n̶o̶t̶ ̶g̶o̶o̶d̶.̶
̶
̶W̶h̶e̶n̶ ̶y̶o̶u̶ ̶s̶t̶a̶r̶t̶e̶d̶ ̶p̶o̶p̶u̶l̶e̶s̶_̶m̶i̶a̶,̶ ̶d̶i̶d̶ ̶y̶o̶u̶ ̶s̶e̶e̶ ̶l̶i̶n̶e̶s̶ ̶l̶o̶o̶k̶i̶n̶g̶ ̶l̶i̶k̶e̶:̶

̶ ̶ ̶-̶ ̶M̶i̶a̶ ̶i̶n̶ ̶"̶d̶e̶v̶e̶l̶o̶p̶e̶r̶"̶ ̶m̶o̶d̶e̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶ ̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶:̶ ̶1̶.̶4̶.̶0̶-̶d̶e̶v̶+̶e̶f̶a̶f̶b̶9̶0̶a̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶c̶a̶p̶s̶u̶l̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶c̶a̶p̶s̶u̶l̶/̶m̶a̶s̶t̶e̶r̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶s̶o̶m̶a̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶s̶o̶m̶a̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶

̶(̶w̶i̶t̶h̶ ̶o̶t̶h̶e̶r̶ ̶p̶a̶t̶h̶s̶,̶ ̶o̶f̶ ̶c̶o̶u̶r̶s̶e̶)̶
̶a̶n̶d̶ ̶t̶h̶e̶n̶:̶
̶c̶h̶a̶n̶g̶e̶d̶ ̶p̶y̶t̶h̶o̶n̶ ̶c̶o̶n̶f̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶p̶a̶t̶h̶'̶:̶ ̶[̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶c̶a̶p̶s̶u̶l̶/̶m̶a̶s̶t̶e̶r̶'̶,̶ ̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶s̶o̶m̶a̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶s̶o̶m̶a̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶c̶a̶s̶a̶/̶h̶o̶s̶t̶/̶s̶r̶c̶/̶p̶o̶p̶u̶l̶s̶e̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶m̶a̶s̶t̶e̶r̶/̶p̶y̶t̶h̶o̶n̶'̶]̶,̶ ̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶b̶i̶n̶/̶p̶y̶t̶h̶o̶n̶3̶'̶}̶
̶T̶h̶i̶s̶ ̶l̶a̶s̶t̶ ̶l̶i̶n̶e̶ ̶s̶h̶o̶w̶s̶ ̶t̶h̶a̶t̶ ̶p̶a̶t̶h̶s̶ ̶h̶a̶v̶e̶ ̶b̶e̶e̶n̶ ̶a̶d̶d̶e̶d̶ ̶t̶o̶ ̶s̶y̶s̶.̶p̶a̶t̶h̶ ̶i̶n̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶w̶h̶i̶c̶h̶ ̶w̶i̶l̶l̶ ̶b̶e̶ ̶p̶a̶s̶s̶e̶d̶ ̶t̶o̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶s̶.̶ ̶I̶ ̶n̶e̶e̶d̶ ̶t̶o̶ ̶k̶n̶o̶w̶ ̶i̶f̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶j̶u̶s̶t̶ ̶n̶o̶t̶ ̶d̶o̶n̶e̶ ̶i̶n̶ ̶y̶o̶u̶r̶ ̶s̶i̶t̶u̶a̶t̶i̶o̶n̶,̶ ̶o̶r̶ ̶i̶f̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶s̶ ̶n̶o̶t̶ ̶p̶a̶s̶s̶e̶d̶ ̶c̶o̶r̶r̶e̶c̶t̶l̶y̶ ̶t̶o̶ ̶t̶h̶e̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶l̶a̶t̶e̶r̶.̶
̶H̶e̶r̶e̶ ̶I̶ ̶h̶a̶v̶e̶ ̶j̶u̶s̶t̶ ̶t̶r̶i̶e̶d̶ ̶i̶t̶ ̶a̶g̶a̶i̶n̶ ̶a̶n̶d̶ ̶i̶t̶ ̶w̶o̶r̶k̶s̶ ̶f̶o̶r̶ ̶m̶e̶.̶.̶.̶

[servoz]

-̶ ̶c̶o̶n̶f̶i̶g̶:̶
̶ ̶ ̶ ̶ ̶-̶ ̶c̶a̶p̶s̶u̶l̶ ̶b̶r̶a̶n̶c̶h̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶o̶n̶ ̶2̶.̶0̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶o̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶d̶a̶t̶a̶ ̶c̶o̶m̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶d̶a̶t̶a̶_̶t̶e̶s̶t̶s̶/̶P̶h̶i̶l̶i̶p̶s̶_̶f̶i̶l̶e̶s̶/̶D̶a̶t̶a̶_̶p̶a̶t̶i̶e̶n̶t̶ ̶i̶m̶p̶o̶r̶t̶e̶d̶ ̶t̶o̶ ̶m̶i̶a̶ ̶t̶h̶a̶n̶k̶s̶ ̶t̶o̶ ̶m̶r̶i̶_̶c̶o̶n̶v̶ ̶(̶i̶n̶ ̶m̶i̶a̶:̶ ̶F̶i̶l̶e̶ ̶>̶ ̶I̶m̶p̶o̶r̶t̶)̶:̶ ̶o̶n̶e̶ ̶T̶1̶ ̶a̶n̶d̶ ̶o̶n̶e̶ ̶B̶o̶l̶d̶ ̶i̶m̶a̶g̶e̶s̶
̶
̶-̶ ̶S̶m̶o̶o̶t̶h̶ ̶p̶r̶o̶c̶e̶s̶s̶ ̶f̶r̶o̶m̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶l̶i̶b̶r̶a̶r̶y̶ ̶(̶i̶n̶_̶f̶i̶l̶e̶s̶=̶T̶1̶ ̶d̶a̶t̶a̶)̶:̶
̶
̶T̶h̶i̶s̶ ̶i̶s̶ ̶t̶h̶e̶ ̶c̶o̶m̶p̶l̶e̶t̶e̶ ̶s̶t̶a̶n̶d̶a̶r̶d̶ ̶o̶u̶t̶p̶u̶t̶,̶ ̶l̶a̶u̶n̶c̶h̶ ̶o̶f̶ ̶m̶i̶a̶,̶ ̶i̶n̶i̶t̶ ̶a̶n̶d̶ ̶r̶u̶n̶:̶ ̶

̶$̶ ̶m̶i̶a̶
̶
̶-̶ ̶M̶i̶a̶ ̶i̶n̶ ̶"̶d̶e̶v̶e̶l̶o̶p̶e̶r̶"̶ ̶m̶o̶d̶e̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶ ̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶:̶ ̶1̶.̶4̶.̶0̶-̶d̶e̶v̶+̶e̶f̶a̶f̶b̶9̶0̶a̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶c̶a̶p̶s̶u̶l̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶
̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶.̶y̶m̶l̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶d̶e̶t̶e̶c̶t̶e̶d̶.̶
̶c̶h̶a̶n̶g̶e̶d̶ ̶p̶y̶t̶h̶o̶n̶ ̶c̶o̶n̶f̶:̶ ̶{̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶b̶i̶n̶/̶p̶y̶t̶h̶o̶n̶3̶'̶,̶ ̶'̶p̶a̶t̶h̶'̶:̶ ̶[̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶'̶]̶}̶
̶
̶C̶h̶e̶c̶k̶i̶n̶g̶ ̶t̶h̶e̶ ̶i̶n̶s̶t̶a̶l̶l̶e̶d̶ ̶v̶e̶r̶s̶i̶o̶n̶s̶ ̶o̶f̶ ̶n̶i̶p̶y̶p̶e̶ ̶a̶n̶d̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶.̶.̶.̶
̶
̶*̶*̶ ̶m̶i̶a̶ ̶i̶s̶ ̶a̶l̶r̶e̶a̶d̶y̶ ̶u̶s̶i̶n̶g̶ ̶t̶h̶e̶ ̶c̶u̶r̶r̶e̶n̶t̶ ̶i̶n̶s̶t̶a̶l̶l̶e̶d̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶o̶f̶ ̶n̶i̶p̶y̶p̶e̶ ̶a̶n̶d̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶f̶o̶r̶ ̶t̶h̶i̶s̶ ̶s̶t̶a̶t̶i̶o̶n̶ ̶(̶1̶.̶6̶.̶0̶-̶d̶e̶v̶ ̶a̶n̶d̶ ̶1̶.̶5̶.̶0̶-̶d̶e̶v̶+̶9̶0̶a̶b̶6̶b̶1̶,̶ ̶r̶e̶s̶p̶e̶c̶t̶i̶v̶e̶l̶y̶)̶
̶
̶i̶n̶i̶t̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶.̶.̶.̶
̶C̶o̶m̶p̶l̶e̶t̶i̶o̶n̶.̶.̶.̶
̶c̶o̶m̶p̶l̶e̶t̶i̶o̶n̶ ̶d̶o̶n̶e̶.̶
̶r̶u̶n̶n̶i̶n̶g̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶.̶.̶.̶
̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶s̶t̶a̶r̶t̶i̶n̶g̶ ̶i̶n̶ ̶l̶i̶g̶h̶t̶ ̶m̶o̶d̶e̶
̶W̶o̶r̶k̶f̶l̶o̶w̶ ̶c̶o̶n̶t̶r̶o̶l̶l̶e̶r̶ ̶i̶n̶i̶t̶i̶a̶l̶i̶s̶e̶d̶
̶
̶ ̶W̶h̶e̶n̶ ̶t̶h̶e̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶ ̶w̶a̶s̶ ̶l̶a̶u̶n̶c̶h̶e̶d̶,̶ ̶t̶h̶e̶ ̶f̶o̶l̶l̶o̶w̶i̶n̶g̶ ̶e̶x̶c̶e̶p̶t̶i̶o̶n̶ ̶w̶a̶s̶ ̶r̶a̶i̶s̶e̶d̶:̶ ̶E̶r̶r̶o̶r̶ ̶d̶u̶r̶i̶n̶g̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶e̶x̶e̶c̶u̶t̶i̶o̶n̶.̶ ̶S̶t̶a̶t̶u̶s̶=̶(̶'̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶'̶,̶ ̶1̶,̶ ̶N̶o̶n̶e̶,̶ ̶N̶o̶n̶e̶)̶.̶
̶T̶h̶e̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶h̶a̶s̶ ̶n̶o̶t̶ ̶b̶e̶e̶n̶ ̶r̶e̶m̶o̶v̶e̶d̶ ̶f̶r̶o̶m̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶a̶n̶d̶ ̶m̶u̶s̶t̶ ̶b̶e̶ ̶d̶e̶l̶e̶t̶e̶d̶ ̶m̶a̶n̶u̶a̶l̶l̶y̶.̶ ̶
̶F̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶1̶0̶4̶]̶
̶A̶b̶o̶r̶t̶e̶d̶/̶k̶i̶l̶l̶e̶d̶ ̶j̶o̶b̶s̶:̶ ̶[̶]̶
̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶=̶
̶-̶-̶-̶-̶ ̶f̶a̶i̶l̶e̶d̶ ̶j̶o̶b̶ ̶i̶n̶f̶o̶ ̶-̶-̶-̶
̶*̶ ̶j̶o̶b̶:̶ ̶1̶0̶4̶:̶ ̶s̶m̶o̶o̶t̶h̶1̶
̶*̶ ̶e̶x̶i̶t̶ ̶s̶t̶a̶t̶u̶s̶:̶ ̶f̶i̶n̶i̶s̶h̶e̶d̶_̶r̶e̶g̶u̶l̶a̶r̶l̶y̶
̶*̶ ̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶:̶
̶'̶p̶y̶t̶h̶o̶n̶3̶'̶ ̶'̶-̶c̶'̶ ̶'̶f̶r̶o̶m̶ ̶c̶a̶p̶s̶u̶l̶.̶a̶p̶i̶ ̶i̶m̶p̶o̶r̶t̶ ̶P̶r̶o̶c̶e̶s̶s̶;̶ ̶P̶r̶o̶c̶e̶s̶s̶.̶r̶u̶n̶_̶f̶r̶o̶m̶_̶c̶o̶m̶m̶a̶n̶d̶l̶i̶n̶e̶(̶"̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶.̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶.̶s̶p̶m̶.̶s̶p̶a̶t̶i̶a̶l̶_̶p̶r̶e̶p̶r̶o̶c̶e̶s̶s̶i̶n̶g̶.̶S̶m̶o̶o̶t̶h̶"̶)̶'̶
̶*̶ ̶e̶x̶i̶t̶ ̶v̶a̶l̶u̶e̶:̶ ̶1̶
̶*̶ ̶t̶e̶r̶m̶ ̶s̶i̶g̶n̶a̶l̶:̶ ̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶e̶n̶v̶ ̶-̶-̶-̶-̶
̶N̶o̶n̶e̶
̶-̶-̶-̶-̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶-̶-̶-̶-̶
̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶s̶p̶m̶'̶:̶ ̶{̶'̶c̶o̶n̶f̶i̶g̶_̶i̶d̶'̶:̶ ̶'̶s̶p̶m̶1̶2̶-̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶c̶o̶n̶f̶i̶g̶_̶e̶n̶v̶i̶r̶o̶n̶m̶e̶n̶t̶'̶:̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶'̶d̶i̶r̶e̶c̶t̶o̶r̶y̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶l̶o̶c̶a̶l̶/̶S̶P̶M̶/̶s̶p̶m̶1̶2̶_̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶,̶ ̶'̶v̶e̶r̶s̶i̶o̶n̶'̶:̶ ̶'̶1̶2̶'̶,̶ ̶'̶s̶t̶a̶n̶d̶a̶l̶o̶n̶e̶'̶:̶ ̶T̶r̶u̶e̶}̶,̶ ̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶'̶:̶ ̶{̶'̶u̶s̶e̶s̶'̶:̶ ̶{̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶:̶ ̶'̶a̶n̶y̶'̶}̶}̶}̶}̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶o̶u̶t̶ ̶-̶-̶-̶-̶
̶
̶-̶-̶-̶-̶ ̶s̶t̶d̶e̶r̶r̶ ̶-̶-̶-̶-̶
̶T̶r̶a̶c̶e̶b̶a̶c̶k̶ ̶(̶m̶o̶s̶t̶ ̶r̶e̶c̶e̶n̶t̶ ̶c̶a̶l̶l̶ ̶l̶a̶s̶t̶)̶:̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶<̶s̶t̶r̶i̶n̶g̶>̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶,̶ ̶i̶n̶ ̶<̶m̶o̶d̶u̶l̶e̶>̶
̶M̶o̶d̶u̶l̶e̶N̶o̶t̶F̶o̶u̶n̶d̶E̶r̶r̶o̶r̶:̶ ̶N̶o̶ ̶m̶o̶d̶u̶l̶e̶ ̶n̶a̶m̶e̶d̶ ̶'̶c̶a̶p̶s̶u̶l̶'̶
̶ ̶.̶.̶.̶

[denisri]

̶T̶h̶e̶n̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶s̶ ̶c̶o̶r̶r̶e̶c̶t̶l̶y̶ ̶d̶e̶t̶e̶c̶t̶e̶d̶ ̶a̶n̶d̶ ̶s̶e̶t̶u̶p̶,̶ ̶b̶u̶t̶ ̶n̶o̶t̶ ̶p̶a̶s̶s̶e̶d̶ ̶t̶o̶ ̶t̶h̶e̶ ̶j̶o̶b̶,̶ ̶o̶r̶ ̶i̶t̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶r̶e̶s̶e̶t̶ ̶b̶e̶f̶o̶r̶e̶ ̶s̶t̶a̶r̶t̶i̶n̶g̶ ̶t̶h̶e̶ ̶j̶o̶b̶,̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶n̶ ̶t̶h̶e̶ ̶e̶r̶r̶o̶r̶ ̶l̶o̶g̶ ̶d̶o̶e̶s̶ ̶n̶o̶t̶ ̶m̶a̶t̶c̶h̶ ̶w̶h̶a̶t̶ ̶i̶s̶ ̶d̶e̶t̶e̶c̶t̶e̶d̶ ̶a̶t̶ ̶s̶t̶a̶r̶t̶u̶p̶.̶
̶I̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶,̶ ̶c̶a̶n̶ ̶y̶o̶u̶ ̶c̶h̶e̶c̶k̶ ̶i̶n̶ ̶t̶h̶e̶ ̶p̶r̶e̶f̶e̶r̶e̶n̶c̶e̶s̶,̶ ̶p̶i̶p̶e̶l̶i̶n̶e̶ ̶t̶a̶b̶,̶ ̶t̶h̶e̶n̶ ̶c̶l̶i̶c̶k̶ ̶"̶e̶d̶i̶t̶ ̶C̶A̶P̶S̶U̶L̶ ̶c̶o̶n̶f̶i̶g̶"̶,̶ ̶a̶n̶d̶ ̶l̶o̶o̶k̶ ̶a̶t̶ ̶t̶h̶e̶ ̶"̶p̶y̶t̶h̶o̶n̶"̶ ̶t̶a̶b̶,̶ ̶t̶o̶ ̶s̶e̶e̶ ̶i̶f̶ ̶y̶o̶u̶ ̶s̶t̶i̶l̶l̶ ̶s̶e̶e̶ ̶t̶h̶e̶ ̶d̶e̶t̶e̶c̶t̶e̶d̶ ̶p̶a̶t̶h̶s̶ ̶o̶r̶ ̶i̶f̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶r̶e̶s̶e̶t̶ ̶s̶o̶m̶e̶w̶h̶e̶r̶e̶ ̶?̶

[servoz]

̶ ̶c̶o̶n̶f̶i̶g̶:̶
̶ ̶ ̶ ̶ ̶-̶ ̶c̶a̶p̶s̶u̶l̶ ̶b̶r̶a̶n̶c̶h̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶ ̶o̶n̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶o̶n̶ ̶2̶.̶0̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶o̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶ ̶ ̶ ̶ ̶-̶ ̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶o̶n̶ ̶t̶h̶e̶ ̶m̶a̶s̶t̶e̶r̶ ̶b̶r̶a̶n̶c̶h̶
̶
̶I̶'̶m̶ ̶a̶f̶r̶a̶i̶d̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶r̶e̶s̶e̶t̶ ̶s̶o̶m̶e̶w̶h̶e̶r̶e̶:̶

[denisri]

̶Y̶e̶s̶,̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶r̶e̶s̶e̶t̶ ̶s̶o̶m̶e̶w̶h̶e̶r̶e̶.̶ ̶A̶r̶e̶ ̶y̶o̶u̶ ̶s̶o̶u̶r̶c̶e̶s̶ ̶u̶p̶-̶t̶o̶-̶d̶a̶t̶e̶ ̶?̶ ̶(̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶b̶r̶a̶n̶c̶h̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶2̶_̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶,̶ ̶c̶h̶a̶n̶g̶e̶s̶e̶t̶ ̶e̶f̶a̶f̶b̶9̶0̶a̶0̶8̶1̶d̶3̶f̶2̶3̶9̶9̶f̶c̶6̶b̶e̶6̶a̶b̶5̶f̶9̶c̶3̶c̶ ̶?̶
̶I̶t̶'̶s̶ ̶w̶e̶i̶r̶d̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶h̶a̶v̶e̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶b̶e̶h̶a̶v̶i̶o̶r̶.̶.̶.̶
̶I̶ ̶s̶t̶i̶l̶l̶ ̶h̶a̶v̶e̶ ̶a̶n̶o̶t̶h̶e̶r̶ ̶p̶r̶o̶b̶l̶e̶m̶ ̶i̶n̶ ̶c̶o̶n̶f̶i̶g̶s̶ ̶t̶h̶a̶t̶ ̶I̶'̶m̶ ̶t̶r̶y̶i̶n̶g̶ ̶t̶o̶ ̶f̶i̶x̶,̶ ̶s̶o̶ ̶e̶v̶e̶r̶y̶t̶h̶i̶n̶g̶ ̶s̶h̶o̶u̶l̶d̶ ̶n̶o̶t̶ ̶b̶e̶ ̶O̶K̶ ̶y̶e̶t̶,̶ ̶b̶u̶t̶ ̶i̶t̶ ̶s̶h̶o̶u̶l̶d̶ ̶n̶o̶t̶ ̶a̶f̶f̶e̶c̶t̶ ̶t̶h̶i̶s̶ ̶p̶a̶r̶t̶.̶

[servoz]

̶Y̶e̶s̶ ̶a̶l̶l̶ ̶s̶o̶u̶r̶c̶e̶s̶ ̶a̶r̶e̶ ̶u̶p̶ ̶t̶o̶ ̶d̶a̶t̶e̶.̶ ̶O̶k̶ ̶I̶ ̶w̶i̶l̶l̶ ̶c̶h̶e̶c̶k̶ ̶a̶g̶a̶i̶n̶ ̶.̶.̶.̶

[servoz]

̶J̶u̶s̶t̶ ̶c̶h̶e̶c̶k̶e̶d̶,̶ ̶I̶ ̶u̶s̶e̶ ̶f̶r̶e̶s̶h̶ ̶s̶o̶u̶r̶c̶e̶s̶ ̶.̶.̶.̶
̶o̶k̶ ̶I̶ ̶w̶i̶l̶l̶ ̶s̶e̶a̶r̶c̶h̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶W̶e̶r̶e̶w̶o̶l̶f̶ ̶h̶i̶d̶d̶e̶n̶ ̶.̶.̶.̶ ̶I̶ ̶t̶h̶i̶n̶k̶ ̶i̶t̶ ̶w̶o̶u̶l̶d̶ ̶b̶e̶ ̶n̶i̶c̶e̶ ̶i̶f̶ ̶y̶o̶u̶ ̶c̶o̶u̶l̶d̶ ̶g̶i̶v̶e̶ ̶m̶e̶,̶ ̶o̶n̶e̶ ̶o̶f̶ ̶t̶h̶e̶s̶e̶ ̶d̶a̶y̶s̶,̶ ̶s̶o̶m̶e̶ ̶n̶o̶t̶i̶o̶n̶s̶ ̶a̶b̶o̶u̶t̶ ̶t̶h̶e̶ ̶n̶e̶w̶ ̶c̶a̶p̶s̶u̶l̶e̶n̶g̶i̶n̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶m̶e̶c̶h̶a̶n̶i̶s̶m̶s̶ ̶i̶n̶ ̶o̶r̶d̶e̶r̶ ̶t̶o̶ ̶ ̶s̶a̶v̶e̶ ̶m̶y̶ ̶t̶i̶m̶e̶ ̶r̶a̶t̶h̶e̶r̶ ̶t̶h̶a̶n̶ ̶d̶i̶s̶c̶o̶v̶e̶r̶i̶n̶g̶ ̶e̶v̶e̶r̶y̶t̶h̶i̶n̶g̶ ̶w̶h̶i̶l̶e̶ ̶r̶e̶a̶d̶i̶n̶g̶ ̶!̶

[denisri]

̶I ̶h̶a̶v̶e̶ ̶p̶u̶s̶h̶e̶d̶ ̶c̶o̶d̶e̶ ̶i̶n̶ ̶s̶o̶m̶a̶-̶b̶a̶s̶e̶,̶ ̶c̶a̶p̶s̶u̶l̶ ̶(̶r̶i̶g̶h̶t̶ ̶n̶o̶w̶)̶,̶ ̶a̶n̶d̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶,̶ ̶t̶o̶ ̶f̶i̶x̶ ̶a̶ ̶f̶e̶w̶ ̶i̶s̶s̶u̶e̶s̶ ̶i̶n̶ ̶c̶o̶n̶f̶i̶g̶s̶.̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶t̶h̶i̶n̶k̶ ̶t̶h̶i̶s̶ ̶w̶i̶l̶l̶ ̶s̶o̶l̶v̶e̶ ̶y̶o̶u̶r̶ ̶p̶r̶o̶b̶l̶e̶m̶,̶ ̶b̶u̶t̶ ̶a̶s̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶ ̶w̶h̶e̶r̶e̶ ̶i̶t̶ ̶c̶o̶m̶e̶s̶ ̶f̶r̶o̶m̶,̶ ̶n̶o̶b̶o̶d̶y̶ ̶k̶n̶o̶w̶s̶.̶.̶.̶ ̶;̶)̶

[denisri]

In a few words: CapsulEngine has a settings section (a Settings object) which holds several configurations, which are separated by "environment" (computing resources) and by module (spm, matlab, etc). Settings are stored in a populse_db (v2 preferably for thread-safety) database. It's a bit tricky in there because there is code to synchronize these settings with the former StudyConfig object. Never mind.
Processes have requirements: may require some config modules to be setup, and maybe have specificities on the values (require spm >= 12 for instance). These requirements are used to select a config modules set for this process. The config is passed to process executions by soma-workflow, through a json file. The python config module is also used to setup the python executable and sys.path to run processes which are running python.
During execution a process is free either to use config items from the json dict, or use functions in Capsul to setup things (matlab, spm, or nipype globals, for instance).

[servoz]

̶N̶o̶ ̶i̶t̶'̶s̶ ̶s̶t̶i̶l̶l̶ ̶n̶o̶t̶ ̶w̶o̶r̶k̶i̶n̶g̶ ̶w̶i̶t̶h̶ ̶f̶r̶e̶s̶h̶ ̶s̶o̶u̶r̶c̶e̶s̶ ̶.̶.̶.̶
̶I̶ ̶w̶o̶n̶d̶e̶r̶ ̶i̶f̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶n̶o̶t̶ ̶o̶b̶s̶e̶r̶v̶i̶n̶g̶ ̶t̶h̶e̶ ̶p̶r̶o̶b̶l̶e̶m̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶y̶o̶u̶ ̶a̶r̶e̶ ̶i̶n̶ ̶C̶A̶S̶A̶_̶D̶I̶S̶T̶R̶O̶ ̶m̶o̶d̶e̶.̶ ̶M̶a̶y̶b̶e̶ ̶i̶t̶ ̶w̶o̶u̶l̶d̶ ̶b̶e̶ ̶a̶ ̶g̶o̶o̶d̶ ̶i̶d̶e̶a̶ ̶(̶i̶t̶'̶s̶ ̶n̶o̶t̶ ̶t̶h̶a̶t̶ ̶l̶o̶n̶g̶ ̶t̶o̶ ̶t̶e̶s̶t̶)̶ ̶t̶o̶ ̶t̶r̶y̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶s̶t̶y̶l̶e̶ ̶o̶f̶ ̶d̶e̶p̶o̶s̶i̶t̶ ̶a̶s̶ ̶f̶o̶r̶ ̶m̶y̶ ̶s̶o̶u̶r̶c̶e̶s̶:̶ ̶C̶l̶o̶n̶e̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶p̶o̶p̶u̶l̶s̶e̶ ̶p̶a̶c̶k̶a̶g̶e̶s̶ ̶i̶n̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶d̶i̶r̶e̶c̶t̶o̶r̶y̶ ̶(̶g̶i̶t̶ ̶c̶l̶o̶n̶e̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶g̶i̶t̶h̶u̶b̶.̶c̶o̶m̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶.̶g̶i̶t̶;̶ ̶g̶i̶t̶ ̶c̶l̶o̶n̶e̶ ̶h̶t̶t̶p̶s̶:̶/̶/̶g̶i̶t̶h̶u̶b̶.̶c̶o̶m̶/̶p̶o̶p̶u̶l̶s̶e̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶.̶g̶i̶t̶;̶ ̶e̶t̶c̶.̶ ̶i̶n̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶d̶i̶r̶e̶c̶t̶o̶r̶y̶)̶ ̶?̶?̶
̶I̶n̶ ̶o̶t̶h̶e̶r̶ ̶h̶a̶n̶d̶,̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶:̶
̶i̶n̶ ̶m̶i̶a̶'̶s̶ ̶m̶a̶i̶n̶.̶p̶y̶:̶
̶p̶c̶ ̶i̶s̶ ̶c̶r̶e̶a̶t̶e̶d̶ ̶a̶s̶ ̶(̶i̶n̶ ̶m̶y̶ ̶c̶a̶s̶e̶)̶:̶
̶{̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶b̶i̶n̶/̶p̶y̶t̶h̶o̶n̶3̶'̶,̶ ̶'̶p̶a̶t̶h̶'̶:̶ ̶[̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶'̶]̶}̶.̶
̶o̶k̶ ̶t̶h̶i̶s̶ ̶i̶s̶ ̶e̶x̶a̶c̶t̶l̶y̶ ̶w̶h̶a̶t̶ ̶w̶e̶ ̶n̶e̶e̶d̶.̶
̶B̶u̶t̶ ̶t̶h̶e̶n̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶:̶
̶c̶o̶n̶f̶i̶g̶.̶u̶p̶d̶a̶t̶e̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶
̶c̶o̶n̶f̶i̶g̶.̶s̶a̶v̶e̶C̶o̶n̶f̶i̶g̶(̶)̶
̶W̶h̶e̶n̶ ̶I̶ ̶r̶e̶a̶d̶ ̶t̶h̶e̶s̶e̶ ̶t̶w̶o̶ ̶m̶e̶t̶h̶o̶d̶s̶ ̶i̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶.̶s̶o̶f̶t̶w̶a̶r̶e̶_̶p̶r̶o̶p̶e̶r̶t̶i̶e̶s̶.̶C̶o̶n̶f̶i̶g̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶s̶e̶e̶ ̶h̶o̶w̶ ̶w̶e̶ ̶c̶a̶n̶ ̶p̶r̶o̶p̶a̶g̶a̶t̶e̶ ̶t̶h̶e̶ ̶p̶c̶ ̶o̶b̶j̶e̶c̶t̶ ̶.̶.̶.̶ ̶?̶

[servoz]

̶o̶k̶ ̶t̶h̶a̶n̶k̶s̶ ̶f̶o̶r̶ ̶t̶h̶e̶ ̶f̶e̶w̶ ̶w̶o̶r̶d̶s̶ ̶o̶n̶ ̶C̶a̶p̶s̶u̶l̶E̶n̶g̶i̶n̶e̶!̶

[denisri]

̶>̶ ̶I̶n̶ ̶o̶t̶h̶e̶r̶ ̶h̶a̶n̶d̶,̶ ̶t̶h̶e̶r̶e̶ ̶i̶s̶ ̶s̶o̶m̶e̶t̶h̶i̶n̶g̶ ̶I̶ ̶d̶o̶n̶'̶t̶ ̶u̶n̶d̶e̶r̶s̶t̶a̶n̶d̶:̶
̶
̶̶c̶o̶n̶f̶i̶g̶.̶u̶p̶d̶a̶t̶e̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶̶ ̶i̶s̶ ̶u̶s̶e̶d̶ ̶t̶o̶ ̶k̶e̶e̶p̶ ̶t̶h̶e̶ ̶̶C̶a̶p̶s̶u̶l̶E̶n̶g̶i̶n̶e̶̶ ̶̶S̶e̶t̶t̶i̶n̶g̶s̶̶ ̶o̶b̶j̶e̶c̶t̶ ̶(̶a̶n̶d̶ ̶i̶n̶t̶e̶r̶n̶a̶l̶ ̶d̶a̶t̶a̶b̶a̶s̶e̶)̶ ̶i̶n̶ ̶s̶y̶n̶c̶ ̶w̶i̶t̶h̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶d̶i̶c̶t̶.̶
̶̶c̶o̶n̶f̶i̶g̶.̶s̶a̶v̶e̶C̶o̶n̶f̶i̶g̶(̶)̶̶ ̶i̶s̶ ̶u̶s̶e̶d̶ ̶t̶o̶ ̶s̶t̶o̶r̶e̶ ̶t̶h̶e̶ ̶f̶u̶l̶l̶ ̶c̶o̶n̶f̶i̶g̶ ̶(̶M̶I̶A̶ ̶+̶ ̶c̶a̶p̶s̶u̶l̶)̶ ̶o̶n̶ ̶d̶i̶s̶k̶ ̶i̶n̶ ̶a̶ ̶j̶s̶o̶n̶ ̶f̶i̶l̶e̶.̶
̶
̶T̶h̶i̶s̶ ̶i̶s̶ ̶n̶e̶e̶d̶e̶d̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶̶C̶o̶n̶f̶i̶g̶(̶)̶̶ ̶i̶s̶ ̶r̶e̶-̶c̶r̶e̶a̶t̶e̶d̶ ̶e̶v̶e̶r̶y̶w̶h̶e̶r̶e̶ ̶a̶n̶y̶ ̶t̶i̶m̶e̶ ̶i̶t̶ ̶i̶s̶ ̶u̶s̶e̶d̶ ̶(̶w̶h̶i̶c̶h̶ ̶i̶s̶ ̶p̶r̶o̶b̶a̶b̶l̶y̶ ̶a̶ ̶l̶o̶s̶s̶ ̶o̶f̶ ̶p̶e̶r̶f̶o̶r̶m̶a̶n̶c̶e̶/̶t̶i̶m̶e̶ ̶a̶s̶ ̶I̶ ̶h̶a̶v̶e̶ ̶a̶l̶r̶e̶a̶d̶y̶ ̶s̶a̶i̶d̶ ̶;̶)̶ ̶)̶ ̶a̶n̶d̶ ̶̶C̶o̶n̶f̶i̶g̶̶ ̶c̶o̶n̶s̶t̶r̶u̶c̶t̶o̶r̶ ̶l̶o̶a̶d̶s̶ ̶e̶v̶e̶r̶y̶t̶h̶i̶n̶g̶ ̶f̶r̶o̶m̶ ̶d̶i̶s̶k̶ ̶e̶v̶e̶r̶y̶ ̶t̶i̶m̶e̶.̶ ̶S̶o̶ ̶a̶n̶y̶t̶h̶i̶n̶g̶ ̶n̶o̶t̶ ̶s̶a̶v̶e̶d̶ ̶i̶s̶ ̶l̶o̶s̶t̶ ̶a̶l̶m̶o̶s̶t̶ ̶i̶m̶m̶e̶d̶i̶a̶t̶e̶l̶y̶.̶
̶
̶Y̶o̶u̶ ̶c̶a̶n̶ ̶c̶h̶e̶c̶k̶ ̶t̶h̶a̶t̶,̶ ̶a̶f̶t̶e̶r̶ ̶t̶h̶i̶s̶ ̶o̶p̶e̶r̶a̶t̶i̶o̶n̶,̶

̶p̶r̶i̶n̶t̶(̶C̶o̶n̶f̶i̶g̶(̶)̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶[̶'̶e̶n̶g̶i̶n̶e̶'̶]̶[̶'̶g̶l̶o̶b̶a̶l̶'̶]̶[̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶]̶)̶
̶s̶h̶o̶u̶l̶d̶ ̶p̶r̶i̶n̶t̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶ ̶t̶h̶i̶n̶g̶s̶ ̶w̶i̶t̶h̶ ̶v̶a̶l̶i̶d̶ ̶p̶a̶t̶h̶s̶.̶ ̶W̶e̶ ̶c̶a̶n̶ ̶p̶r̶i̶n̶t̶ ̶t̶h̶i̶s̶ ̶h̶e̶r̶e̶ ̶a̶n̶d̶ ̶t̶h̶e̶r̶e̶ ̶i̶n̶ ̶t̶h̶e̶ ̶c̶o̶d̶e̶ ̶t̶o̶ ̶s̶e̶e̶ ̶w̶h̶e̶n̶ ̶t̶h̶e̶ ̶i̶n̶f̶o̶ ̶g̶e̶t̶s̶ ̶l̶o̶s̶t̶.̶
̶
̶I̶f̶ ̶n̶e̶e̶d̶e̶d̶ ̶I̶ ̶w̶i̶l̶l̶ ̶r̶e̶i̶n̶s̶t̶a̶l̶l̶ ̶a̶l̶l̶ ̶s̶o̶u̶r̶c̶e̶s̶ ̶w̶h̶e̶n̶ ̶I̶ ̶g̶e̶t̶ ̶t̶i̶m̶e̶ ̶b̶u̶t̶ ̶i̶t̶'̶s̶ ̶a̶ ̶b̶i̶t̶ ̶l̶o̶n̶g̶ ̶s̶i̶n̶c̶e̶ ̶I̶ ̶h̶a̶v̶e̶ ̶n̶o̶t̶ ̶a̶ ̶v̶e̶r̶y̶ ̶g̶o̶o̶d̶ ̶n̶e̶t̶w̶o̶r̶k̶ ̶r̶i̶g̶h̶t̶ ̶n̶o̶w̶ ̶a̶n̶d̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶i̶s̶ ̶h̶u̶g̶e̶ ̶w̶i̶t̶h̶ ̶a̶l̶l̶ ̶t̶h̶e̶ ̶d̶a̶t̶a̶ ̶i̶n̶ ̶i̶t̶ ̶(̶m̶o̶r̶e̶o̶v̶e̶r̶ ̶I̶ ̶h̶a̶v̶e̶ ̶s̶e̶v̶e̶r̶a̶l̶ ̶m̶e̶e̶t̶i̶n̶g̶s̶ ̶t̶h̶e̶ ̶n̶e̶x̶t̶ ̶d̶a̶y̶s̶ ̶a̶n̶d̶ ̶I̶ ̶w̶i̶l̶l̶ ̶n̶o̶t̶ ̶h̶a̶v̶e̶ ̶m̶u̶c̶h̶ ̶t̶i̶m̶e̶ ̶f̶o̶r̶ ̶c̶o̶d̶i̶n̶g̶)̶.̶
̶A̶n̶d̶ ̶I̶'̶m̶ ̶n̶o̶t̶ ̶s̶u̶r̶e̶ ̶t̶h̶e̶ ̶c̶a̶s̶a̶-̶d̶i̶s̶t̶r̶o̶ ̶s̶i̶t̶u̶a̶t̶i̶o̶n̶ ̶w̶o̶u̶l̶d̶ ̶c̶h̶a̶n̶g̶e̶ ̶m̶u̶c̶h̶:̶ ̶a̶p̶a̶r̶t̶ ̶f̶r̶o̶m̶ ̶t̶h̶e̶ ̶p̶a̶t̶h̶s̶ ̶t̶h̶e̶m̶s̶e̶l̶v̶e̶s̶ ̶w̶h̶i̶c̶h̶ ̶a̶r̶e̶ ̶d̶i̶f̶f̶e̶r̶e̶n̶t̶,̶ ̶t̶h̶e̶ ̶r̶e̶s̶t̶ ̶s̶h̶o̶u̶l̶d̶ ̶b̶e̶ ̶t̶h̶e̶ ̶s̶a̶m̶e̶.̶ ̶B̶u̶t̶ ̶y̶e̶s̶ ̶I̶ ̶w̶i̶l̶l̶ ̶t̶r̶y̶.̶

[servoz]

̶I̶f̶ ̶I̶ ̶p̶u̶t̶ ̶
̶̶p̶r̶i̶n̶t̶(̶C̶o̶n̶f̶i̶g̶(̶)̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶[̶'̶e̶n̶g̶i̶n̶e̶'̶]̶[̶'̶g̶l̶o̶b̶a̶l̶'̶]̶[̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶]̶)̶̶
̶l̶i̶k̶e̶:̶

̶ ̶ ̶ ̶ ̶i̶f̶ ̶D̶E̶V̶_̶M̶O̶D̶E̶ ̶a̶n̶d̶ ̶p̶y̶p̶a̶t̶h̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶c̶o̶n̶f̶i̶g̶ ̶=̶ ̶C̶o̶n̶f̶i̶g̶(̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶c̶o̶n̶f̶i̶g̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶e̶n̶g̶i̶n̶e̶(̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶c̶ ̶=̶ ̶c̶o̶n̶f̶i̶g̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶p̶c̶ ̶=̶ ̶c̶.̶s̶e̶t̶d̶e̶f̶a̶u̶l̶t̶(̶'̶e̶n̶g̶i̶n̶e̶'̶,̶ ̶{̶}̶)̶.̶s̶e̶t̶d̶e̶f̶a̶u̶l̶t̶(̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶'̶g̶l̶o̶b̶a̶l̶'̶,̶ ̶{̶}̶)̶.̶s̶e̶t̶d̶e̶f̶a̶u̶l̶t̶(̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶{̶}̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶i̶f̶ ̶n̶o̶t̶ ̶p̶c̶.̶g̶e̶t̶(̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶)̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶p̶c̶[̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶]̶ ̶=̶ ̶s̶y̶s̶.̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶i̶f̶ ̶n̶o̶t̶ ̶p̶c̶.̶g̶e̶t̶(̶'̶p̶a̶t̶h̶'̶)̶:̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶p̶c̶[̶'̶p̶a̶t̶h̶'̶]̶ ̶=̶ ̶p̶y̶p̶a̶t̶h̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶p̶r̶i̶n̶t̶(̶'̶c̶h̶a̶n̶g̶e̶d̶ ̶p̶y̶t̶h̶o̶n̶ ̶c̶o̶n̶f̶:̶'̶,̶ ̶p̶c̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶c̶o̶n̶f̶i̶g̶.̶u̶p̶d̶a̶t̶e̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶c̶o̶n̶f̶i̶g̶.̶s̶a̶v̶e̶C̶o̶n̶f̶i̶g̶(̶)̶
̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶ ̶p̶r̶i̶n̶t̶(̶C̶o̶n̶f̶i̶g̶(̶)̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶[̶'̶e̶n̶g̶i̶n̶e̶'̶]̶[̶'̶g̶l̶o̶b̶a̶l̶'̶]̶[̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶]̶)̶
̶

̶I̶ ̶o̶b̶s̶e̶r̶v̶e̶ ̶a̶ ̶c̶r̶a̶s̶h̶ ̶o̶f̶ ̶m̶i̶a̶ ̶a̶t̶ ̶s̶t̶a̶r̶t̶u̶p̶:̶

̶$̶ ̶m̶i̶a̶
̶
̶-̶ ̶M̶i̶a̶ ̶i̶n̶ ̶"̶d̶e̶v̶e̶l̶o̶p̶e̶r̶"̶ ̶m̶o̶d̶e̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶ ̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶ ̶v̶e̶r̶s̶i̶o̶n̶ ̶:̶ ̶1̶.̶4̶.̶0̶-̶d̶e̶v̶+̶2̶a̶4̶7̶d̶3̶2̶a̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶c̶a̶p̶s̶u̶l̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶s̶o̶m̶a̶_̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶ ̶ ̶.̶ ̶U̶s̶i̶n̶g̶ ̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶ ̶p̶a̶c̶k̶a̶g̶e̶ ̶f̶r̶o̶m̶ ̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶ ̶.̶.̶.̶
̶
̶/̶h̶o̶m̶e̶/̶e̶c̶o̶n̶d̶a̶m̶i̶/̶.̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶c̶o̶n̶f̶i̶g̶u̶r̶a̶t̶i̶o̶n̶.̶y̶m̶l̶ ̶h̶a̶s̶ ̶b̶e̶e̶n̶ ̶d̶e̶t̶e̶c̶t̶e̶d̶.̶
̶c̶h̶a̶n̶g̶e̶d̶ ̶p̶y̶t̶h̶o̶n̶ ̶c̶o̶n̶f̶:̶ ̶{̶'̶e̶x̶e̶c̶u̶t̶a̶b̶l̶e̶'̶:̶ ̶'̶/̶u̶s̶r̶/̶b̶i̶n̶/̶p̶y̶t̶h̶o̶n̶3̶'̶,̶ ̶'̶p̶a̶t̶h̶'̶:̶ ̶[̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶c̶a̶p̶s̶u̶l̶/̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶b̶a̶s̶e̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶s̶o̶m̶a̶-̶w̶o̶r̶k̶f̶l̶o̶w̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶p̶o̶p̶u̶l̶s̶e̶_̶d̶b̶/̶p̶y̶t̶h̶o̶n̶'̶,̶ ̶'̶/̶d̶a̶t̶a̶/̶G̶i̶t̶_̶P̶r̶o̶j̶e̶c̶t̶s̶/̶m̶i̶a̶_̶p̶r̶o̶c̶e̶s̶s̶e̶s̶/̶p̶y̶t̶h̶o̶n̶'̶]̶}̶
̶T̶r̶a̶c̶e̶b̶a̶c̶k̶ ̶(̶m̶o̶s̶t̶ ̶r̶e̶c̶e̶n̶t̶ ̶c̶a̶l̶l̶ ̶l̶a̶s̶t̶)̶:̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶m̶a̶i̶n̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶1̶1̶1̶7̶,̶ ̶i̶n̶ ̶<̶m̶o̶d̶u̶l̶e̶>̶
̶ ̶ ̶ ̶ ̶m̶a̶i̶n̶(̶)̶
̶ ̶ ̶F̶i̶l̶e̶ ̶"̶m̶a̶i̶n̶.̶p̶y̶"̶,̶ ̶l̶i̶n̶e̶ ̶6̶8̶0̶,̶ ̶i̶n̶ ̶m̶a̶i̶n̶
̶ ̶ ̶ ̶ ̶p̶r̶i̶n̶t̶(̶C̶o̶n̶f̶i̶g̶(̶)̶.̶g̶e̶t̶_̶c̶a̶p̶s̶u̶l̶_̶c̶o̶n̶f̶i̶g̶(̶)̶[̶'̶e̶n̶g̶i̶n̶e̶'̶]̶[̶'̶g̶l̶o̶b̶a̶l̶'̶]̶[̶'̶c̶a̶p̶s̶u̶l̶.̶e̶n̶g̶i̶n̶e̶.̶m̶o̶d̶u̶l̶e̶.̶p̶y̶t̶h̶o̶n̶'̶]̶)̶
̶K̶e̶y̶E̶r̶r̶o̶r̶:̶ ̶'̶e̶n̶g̶i̶n̶e̶'̶

̶F̶o̶r̶ ̶m̶e̶ ̶p̶c̶ ̶o̶b̶j̶e̶c̶t̶ ̶i̶s̶ ̶n̶o̶t̶ ̶p̶r̶o̶p̶a̶g̶a̶t̶e̶d̶.̶
̶ ̶I̶a̶m̶ ̶r̶e̶a̶d̶i̶n̶g̶ ̶y̶o̶u̶r̶ ̶a̶d̶d̶i̶t̶i̶o̶n̶s̶ ̶i̶n̶ ̶p̶o̶p̶u̶l̶s̶e̶_̶m̶i̶a̶.̶s̶o̶f̶t̶w̶a̶r̶e̶_̶p̶r̶o̶p̶e̶r̶t̶i̶e̶s̶.̶ ̶I̶ ̶h̶a̶v̶e̶n̶'̶t̶ ̶r̶e̶a̶d̶ ̶e̶n̶o̶u̶g̶h̶ ̶o̶f̶ ̶t̶h̶e̶m̶ ̶y̶e̶t̶ ̶t̶o̶ ̶h̶a̶v̶e̶ ̶a̶ ̶f̶i̶n̶a̶l̶ ̶o̶p̶i̶n̶i̶o̶n̶ ̶;̶-̶)̶

[servoz]

̶o̶k̶ ̶I̶ ̶h̶a̶v̶e̶ ̶a̶ ̶s̶t̶a̶r̶t̶ ̶o̶f̶ ̶e̶x̶p̶l̶a̶n̶a̶t̶i̶o̶n̶ ̶.̶.̶.̶ ̶I̶'̶m̶ ̶d̶i̶g̶g̶i̶n̶g̶ ̶;̶-̶)̶

[denisri]

̶S̶o̶ ̶i̶t̶ ̶s̶e̶e̶m̶s̶ ̶l̶i̶k̶e̶ ̶t̶h̶e̶ ̶c̶o̶n̶f̶i̶g̶ ̶i̶s̶ ̶n̶o̶t̶ ̶p̶r̶o̶p̶e̶r̶l̶y̶ ̶s̶a̶v̶e̶d̶ ̶?̶

[servoz]

The nipypeprocess2 branch style finally causes some problems with the traits which will ultimately make it impossible for the user to save the new pipelines (which is an important feature of mia).
I switch to the nipypeprocess1 style that seems to give better results because the traits are completely defined in the process class, which gives a more robust result.

[servoz]

Oh ! and with nipypeprocess1 we do not observe all the unnecessary exception messages in the stdout ... So I close the opened PR for that. nipypeprocess2 is definitively currently not robust !

[servoz]

The new controller for the V2 is beautiful. Ok ... but currently it doesn't allow to send a list directly.
For example for the smooth brick of mia_processes library, if we send two files for the in_files parameter, only the first file is taken. To have both we need to define in the controller a list of two elements and then add one by one these two elements.
It is heavy and it would be desirable to have the choice between a manual definition or an automatic management in the case of a list sending.
It shouldn't be too difficult to change in the code because that's what is already done for the output smoothed_files parameter ...

Another thing that I haven't explored yet but that might limit the bricks I already have in my personal library (and that I haven't had time to test yet with v2 !).
It can be interesting to be able to easily play with lists of lists, see lists of lists of lists (see more !). I still don't see how to manage this with the new controller ... To be followed when I will test the bricks in question, but it may already be thought that we will have problems with this ...

[servoz]

Ok, I just understood about the previous point for sending a list from the database to the controller.

In the figure below, the filter with the red arrow allows only a manual definition while the filter with the green arrow allows to get a list automatically from the database. Perhaps this should be made more explicit?

Also observed with these two filters.

• with red arrow:
  
• with green arrow:
  

The window title for both cases should be the same. It is very useful to have the name of the parameter in the title as it is the case for the filter opened with the green arrow (the title as with the red arrow "ListController - 0" is not appropriate).

Ok for this point there aren't really big problems, rather small details to make things more explicit.

To come back to the point about the management of lists of lists of lists of lists of lists of lists of lists of lists, etc., mentioned in the previous message, it doesn't change anything and we can expect problems ... to be seen when the time comes !

[servoz]

I still try to make the V2 work as close as possible to the V1.

An interesting feature is the display, on the standard output, of the name of the node (and associated process class) at the time of initialisation.

This can be done quite easily in the MIAProcessCompletionEngine.complete_parameters() method.

It works fine for instances of ProcessMIA.
For example when initialising a mia_processes's Smooth brick we get in the stdout:
. smooth2 (mia_processes.preprocess.spm.spatial_preprocessing.Smooth) process node ...

However, for NipypeProcess instances the result is not perfect for me.
For example for a Smooth brick of spm/nipype we get:
. smooth1 (capsul.process.process.NipypeProcess) process node ...

We have the node in question but I haven't found a way to get the path to the base class (here it should be nipype.interfaces.spm.Smooth).
Is there a way to get this information in the scope of a NipypeProcess object ?

[denisri]

I'm back from holidays. Well, there is a lot of questions/remarks, it will be a bit difficult to answer all in a clear way...
I'll try by steps.

Using the nipypeprocess2 branch style with Smooth brick (mia_processes), we observe an unnecessary exception message in the stdout, every time we change an input parameter, because of the automatic synchronisation.

yes that's a problem difficult to solve: nipype interfaces get some invalid values by default at init time, so calling their _list_outputs() method produce errors if not all parameters have been updated using valid values. But the sync mechanism in NipypeProcess makes use of this method to update and sync parameters between the nipype interface and the Capsul process which contains it, which causes the error. I'm not sure if it should become silent or not... Sometimes it's really a user mistake and it should be visible, and sometimes not...

We have lost an interesting piece of information for the user if he does not respect the type imposed by the traits in the controller. In V1 (branch master for all the populse packages) there is a widget that opens if the user doesn't respect the trait. Let's say we enter 'toto' for the data_type parameter of the Smooth brick of mia_processes:

I had not noticed this point, thanks for pointing it out. I have no clear idea of where/when the popup message was issued. I need to check. However we have to be really really careful about when/where to issue graphical popups, and more specifically how many times we do:

• If the process is inside a huge iteration (thousands of items) the user should not be presented thousands of popups: this is typically a case when a user would get upset to the point he would murder the developer, the software and the computer ;)
• we have to keep in mind non-graphical uses (scripts...) so GUI popups should not be issued in non-graphical contexts. I don't know if they were issued from a part of the code used only in graphical contexts or not. In a more general way, the code should always separate GUI and non-GUI parts. The pipeline manager for instance, in my opinion, shoud be almost completely rewritten to separate this, because it currently mixes graphical parts, widgets, popups, and pipelining machinery that should ideally be available for use in non-graphical scripts.

The nipypeprocess2 branch style finally causes some problems with the traits which will ultimately make it impossible for the user to save the new pipelines (which is an important feature of mia).

Impossible to save ? Do you have an example ? In any case this has to be fixed: we should always be able to save the pipeline.

Ok, I just understood about the previous point for sending a list from the database to the controller.

Yes the controller GUI is not clear here. The GUI is using generic widgets that are embedded recursively: a File will display a filter button (for itself), a List will display several elements of its contents type, so a List of File will display one filter button for each of its elements. Moreover I have a little bit specialized "List of File" to display a filter button at the list level, but then there are several buttons at several levels... We may try to find a way to remove the elements buttons in "List of " I think.

The window title for both cases should be the same. It is very useful to have the name of the parameter in the title as it is the case for the filter opened with the green arrow (the title as with the red arrow "ListController - 0" is not appropriate).

They do not refer to the same thing actually, so must not display the same title. the green arrow is for the list, and allows multiple selection, and is actually for the parameter "in_files". But here the red arrow is for only the item 0 of the list -- one file. A more proper title would be "in_files[0]" maybe, if I find a way to force it in the recursive GUI, which is not very easy...

An interesting feature is the display, on the standard output, of the name of the node (and associated process class) at the time of initialisation.

If the pipeline is reasonably small, yes... If it's thousands of iterations, maybe not...

However, for NipypeProcess instances the result is not perfect for me.
For example for a Smooth brick of spm/nipype we get:
. smooth1 (capsul.process.process.NipypeProcess) process node ...
We have the node in question but I haven't found a way to get the path to the base class (here it should be nipype.interfaces.spm.Smooth).
Is there a way to get this information in the scope of a NipypeProcess object ?

Yes, the thing is that NipipeProcess is (in the general case) not subclassed, so the class name is actually capsul.process.process.NipypeProcess whatever the nipype interface in it. But we may make an exception here: if the class is NipypeProcess, the we can display instead its interface class name (process._nipype_interface.__class__), which is in addition the identifier used to build the process in get_process_instance().

[servoz]

I wanted to start working on the tools chapter of mia_processes for V2 but from the beginning I noticed that there is no more access to the database filter in the controller.

There's something that I miss with the v2 for this very simple type of brick that doesn't overload an already existing class ?

ex. Auto_Filter_List in mia_processes.tools, on branch 2.0

[servoz]

Oh wait a minute ... I observe that this issue seems to exist only with the Auto_Filter_List ... Everything seems ok with all the other classes of mia_processes.tools ...

I investigate ...

[servoz]

Ok I understand ... In V2, to have access to the filter in the controller, therefore to the database, it is now necessary that the trait of the plug is a file (traits.File) !!! This was not the case in V1, which allowed all the plugs to have access to the database even if it was absurd (it can be considered as absurd to give access to the database to retrieve a data which can't be there, like for example a float !; Indeed until now the DataBrowser in mia use only files for each document).

Ok it's clearly an improvement in v2, it's just a matter of changing the coding habits for the bricks a little bit and be careful with the traits that will need access to the database !

[servoz]

Thank you for your answer @denisri.

I didn't comment on it for lack of time but also because these are general questions that can perhaps be dealt with a little later.

However, some of them are neither trivial nor secondary, such as the possibility of iteration, which would be a regression if it was not present in V2 (in a simple, ergonomic, automatic version, in short using the database).

There are other points that worked rather well in V1 and seem to work less well in V2. However, I prefer to focus on mia_processes V2 for now. I hope to be finished soon enough this point.

We will then make visio meeting to discuss the last points to be improved in order to finalise the v2?

PS. it seems that the fork for the PR (denisri:populse_db2_capsulengine) is not synchronised with the
populse_db2_capsulengin branch from populse_mia (on which I pushed some modifications).

[servoz]

This morning it seems impossible to use mia. Importing a node in the pipelime manager seems so long that it is very difficult to use mia. I already made a remark about this in a previous post in this ticket. The problem seemed to be solved, as if by magic, without knowing why ... This morning it reached new heights ... Do you observe this problem from your side ? I opened a ticket at nipype.

$ python3
Python 3.8.6 (default, Sep 25 2020, 00:00:00) 
[GCC 10.2.1 20200723 (Red Hat 10.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
import time: 10.510946035385132

What is curious is that before when I was observing the problem it was only during the first import (this is always the case with the interpreter). Now every time you touch a brick there is such a long waiting time that it is almost impossible to use mia .

[denisri]

So the problem is within nipype itself...
On my laptop I have a python3 installation ("host") and a virtual container (casa-distro).

• On the host system I get the same as you get (10.3 seconds, reproducibly), it has nipype 1.5.1
• in the container the same code runs in 0.23 second, it has nipype 1.1.9.
  So either there has been a change in nipype, or nipype spends time trying to detect things on the system (external software such as SPM).
  Sorry I'm a bit busy and working on other things these days, but I'll come back to mia...

[servoz]

Yes nipype has been using detection tools at least via elemetry for a little while (maybe the problem comes from something else but I've already had problems with slowness because of this one).
Currently this makes it almost impossible to use mia with nipype 1.6 (and 1.5.1 according to what you write).

I'm going to do some investigation to see from what version of nipype the problem comes from (according to what you write the problem is not present with nipype 1.1.9).

Beyond that, it poses the problem of including by default nipipe in mia ... Maybe we should reconsider this position ...

Thank you for your answer @denisri , and no problem, come back whenever you want and can ;-)!

[servoz]

For me too nipype 1.1.9 is fine ...

[servoz]

So:

With traits 4.6 (it seems that there are problems with nipype 1.3.0 and 1.4.0 with traits>4.6):

• nipype 1.2 is fine in mia and:

t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
import time: 0.40441322326660156

• nipype 1.3.0 is fine in mia and:

>>> t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
210112-14:11:59,83 nipype.utils WARNING:
	 Could not check for version updates: 
Connection to server could not be made
import time: 5.5328309535980225

• nipype 1.4.0 is fine in mia and:

>>> t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
210112-14:15:51,228 nipype.utils WARNING:
	 Could not check for version updates: 
Connection to server could not be made
import time: 5.550581455230713

• nipype 1.5.0 is dirty in mia and:

>>> t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
import time: 10.560020446777344

With last version of traits (6.1.1) :

• nipype 1.4.2 is fine in mia and:

 >>> t0 = time.time(); from nipype.interfaces.spm import Smooth; print('import time:', time.time() - t0)
210112-14:26:20,269 nipype.utils WARNING:
	 Could not check for version updates: 
Connection to server could not be made
import time: 5.656156301498413

So I suggest to don't go over nipype 1.4.2 currently.

To keep in mind:
With nipype release > 1.4.2 during the startup of mia which takes an eternity I observed this when I killed mia:

  File "main.py", line 1151, in <module>
    main()
  File "main.py", line 716, in main
    verify_processes()
  File "main.py", line 1097, in verify_processes
    pckg_dic = package.add_package(pckg)
  File "main.py", line 290, in add_package
    get_process_instance(
  File "/data/Git_Projects/capsul/capsul/study_config/process_instance.py", line 141, in get_process_instance
    return _get_process_instance(process_or_id, study_config=study_config,
  File "/data/Git_Projects/capsul/capsul/study_config/process_instance.py", line 343, in _get_process_instance
    result = nipype_factory(module_object())
  File "/home/econdami/.local/lib/python3.8/site-packages/nipype/interfaces/io.py", line 354, in __init__
    super(DataSink, self).__init__(**kwargs)
  File "/home/econdami/.local/lib/python3.8/site-packages/nipype/interfaces/base/core.py", line 178, in __init__
    BaseInterface._etelemetry_version_data = check_latest_version()
  File "/home/econdami/.local/lib/python3.8/site-packages/nipype/__init__.py", line 86, in check_latest_version
    return etelemetry.check_available_version(
  File "/home/econdami/.local/lib/python3.8/site-packages/etelemetry-0.2.2-py3.8.egg/etelemetry/client.py", line 98, in check_available_version
    ret = get_project(project)
  File "/home/econdami/.local/lib/python3.8/site-packages/etelemetry-0.2.2-py3.8.egg/etelemetry/client.py", line 66, in get_project
    res = _etrequest(ET_PROJECTS.format(repo=repo), **rargs)
  File "/home/econdami/.local/lib/python3.8/site-packages/etelemetry-0.2.2-py3.8.egg/etelemetry/client.py", line 33, in _etrequest
    res = request(method, endpoint, params=params, **kwargs)
  File "/usr/lib/python3.8/site-packages/requests/api.py", line 60, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 533, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 646, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 665, in urlopen
    httplib_response = self._make_request(
  File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 376, in _make_request
    self._validate_conn(conn)
  File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 994, in _validate_conn
    conn.connect()
  File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 334, in connect
    conn = self._new_conn()
  File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 156, in _new_conn
    conn = connection.create_connection(
  File "/usr/lib/python3.8/site-packages/urllib3/util/connection.py", line 74, in create_connection
    sock.connect(sa)
KeyboardInterrupt

This suggests that the problem clearly comes from the nypipe check_latest_version which is done automatically. This issue is not within our control but we should find a way to work around it when things go wrong as they do now.

[servoz]

Ok the problem is indeed linked to etelemetry and to an issue with the server which is currently down.

As proposed here a workaround is to define a NO_ET environment variable which bypasses the update checks.

It works on my laptop and we can use the latest version of nipype again with this environment variable.

As we are trying to ban the environment variable in mia as much as possible, I will add it to os.environ as soon as possible.
Mia will work without checking for the latest soft versions available in nipype at all times.

This make a problem for someone?

[denisri]

OK I see.
What's the point of checking systematically the latest version of nipype anyway ? Just to print a message ("you're not using the latest version" or something), or does it actually do anything with the latest available version ? I see no good in always imposing the latest version of something, it's a user choice, or sometimes a software dependency constraint, not a choice of the software itself.
In other words, I'm totally OK to bypass the test.

[servoz]

Done!

[servoz]

As I noticed in a previous comment the new controller is super top better than in the V1 ... But it also seems much more limited in terms of type management a bit more complicated than the simple float, list, etc....

In personal bricks that I didn't have time to modify and evaluate in the V2 I need lists of lists of lists, etc ...

I start to find an example of the limits of the new controller with the NewSegment brick of mia_processes.

There are traits that cause problems:

channel_info:
tissues

We see the default values but we can't change anything. For the first one we don't see "channel_info" !!!!

It's really a big issue if we're limited to the simple types!
EDIT: obviously, we have to use the 2.0 branch of mia_processes to reproduce with NewSegment!

[servoz]

always with the NewSegment brick :
the write_deformation_fields is only available in the controller if we click on the brick (not available with the input node) ...

[servoz]

The V2 version is now functional and all the bricks of mia_processes or nipype work correctly. 😄 🎉
Some improvements to be done have already been noticed.

• Some of them are priority (2) and should be done before definitively releasing version 2 (merge of branches, deployment on pypi, etc.).
• Others are less important and can be dealt with later, knowing that anyway new issues will be raised when really using mia ...

To simplify the work, the goal is to close this now very long ticket, but to not waste the time invested in it, I will try to summarise the important points still unanswered or without action, in new tickets easier to read.
Then I will close this ticket