github.com/upcmd/up@v0.8.1-0.20230108151705-ad8b797bf04f/tests/modtests/0010/doc.yml (about) 1 vars: 2 folder: module 3 title: multi module calls 4 weight: 2150 5 log: yes 6 head: | 7 Showcase the multple module calls 8 9 Things will get complicated if your main task invoke a module A.taskA, then module A result in another task call to module B.taskB. 10 11 Many programming language has the issue of dependency hell. It will break simply becuase of different version of different modules 12 13 UP cmd support two approaches to manage the dependencies, the first one s to manage the dependency statically under a local directory, either it is a relative direectory to your work directory, or abosolute path in your system; the second one is to manage multiple versions of same module in its version directories 14 15 sections: 16 - title: Use local directory as module code base 17 content: | 18 Simply saying, you will define all required modules and versions in that module's configuration upconfig.yml file. It's like a jailed execution for that module to pull all required modules and defined versions 19 20 ``` 21 myproject 22 ├── hello-module 23 │ ├── up.yml 24 │ └── upconfig.yml 25 ├── hi-module 26 │ └── up.yml 27 ├── world-module 28 │ ├── up.yml 29 │ └── upconfig.yml 30 ├── up.yml 31 └── upconfig.yml 32 ``` 33 34 In this case, the call flow is: 35 ``` 36 main task -> hello-module.Say_hello -> hi-module.Say_hi 37 ``` 38 39 The below module config to call hi-module will be under management of hello-module, in myproject/hello-module/upconfig.yml 40 ``` 41 Modules: 42 43 - 44 dir: hi-module/ 45 alias: hi-module 46 ``` 47 48 Please notice that the world-module is configured in the same way, the hi-module is in its own path but not globally shared and dynamically linked 49 50 pros: 51 * the callee module is statically linked 52 * the callee module could be different version, so there is no compatibility issue at all, hence it will utterly avoid problems like below: 53 * the time you upgrade is the time start failing 54 * demanding one version fitting all 55 * demanding you must upgrade all components' version so that the code could work 56 57 con: 58 * none 59 60 When your code is maturer enough, you might want to publish your own local module directory under your project code base. You wrap up code into an exported task, check in your module directory as a git repo. You can start sharing module with different teams and after that you can use the second way to refer to the module using your repo url and remove your local directory from your project code base. 61 62 63 64 - title: config file - upconfig.yml 65 filelookup: upconfig.yml 66 67 - title: up task - up.yml 68 filelookup: up.yml 69 70 - title: up module task - up.yml 71 filelookup: hello-module/up.yml 72 73 - title: up module config - upconfig.yml 74 filelookup: hello-module/upconfig.yml 75 76 - title: hi module task - up.yml 77 filelookup: hi-module/up.yml