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