github.com/containers/libpod@v1.9.4-0.20220419124438-4284fd425507/docs/tutorials/podman-derivative-api.md (about)

     1  ![PODMAN logo](../../logo/podman-logo-source.svg)
     2  
     3  # How to use libpod for custom/derivative projects
     4  
     5  libpod today is a Golang library and a CLI.  The choice of interface you make has advantages and disadvantages.
     6  
     7  Running as a subprocess
     8  ---
     9  
    10  Advantages:
    11  
    12   - Many commands output JSON
    13   - Works with languages other than Golang
    14   - Easy to get started
    15  
    16  Disadvantages:
    17  
    18   - Error handling is harder
    19   - May be slower
    20   - Can't hook into or control low-level things like how images are pulled
    21  
    22  Vendoring into a Go project
    23  ---
    24  
    25  Advantages:
    26  
    27   - Significant power and control
    28  
    29  Disadvantages:
    30  
    31   - You are now on the hook for container runtime security updates (partially, `runc`/`crun` are separate)
    32   - Binary size
    33   - Potential skew between multiple libpod versions operating on the same storage can cause problems
    34  
    35  Varlink
    36  ---
    37  
    38  Some code exists for this; splits the difference.  Future uncertain.
    39  
    40  Making the choice
    41  ---
    42  
    43  A good question to ask first is: Do you want users to be able to use `podman` to manipulate the containers created by your project?
    44  If so, that makes it more likely that you want to run `podman` as a subprocess.  If you want a separate image store and a fundamentally
    45  different experience; if what you're doing with containers is quite different from those created by the `podman` CLI,
    46  that may drive you towards vendoring.