github.com/containers/podman/v5@v5.1.0-rc1/docs/podman-derivative-api (about)

     1  .TH How to use libpod for custom/derivative projects
     2  .PP
     3  libpod today is a Golang library and a CLI.  The choice of interface you make has advantages and disadvantages.
     4  
     5  .SH Running as a subprocess
     6  .PP
     7  Advantages:
     8  
     9  .RS
    10  .IP \(bu 2
    11  Many commands output JSON
    12  .IP \(bu 2
    13  Works with languages other than Golang
    14  .IP \(bu 2
    15  Easy to get started
    16  
    17  .RE
    18  
    19  .PP
    20  Disadvantages:
    21  
    22  .RS
    23  .IP \(bu 2
    24  Error handling is harder
    25  .IP \(bu 2
    26  May be slower
    27  .IP \(bu 2
    28  Can't hook into or control low\-level things like how images are pulled
    29  
    30  .RE
    31  
    32  .SH Vendoring into a Go project
    33  .PP
    34  Advantages:
    35  
    36  .RS
    37  .IP \(bu 2
    38  Significant power and control
    39  
    40  .RE
    41  
    42  .PP
    43  Disadvantages:
    44  
    45  .RS
    46  .IP \(bu 2
    47  You are now on the hook for container runtime security updates (partially, \fB\fCrunc\fR/\fB\fCcrun\fR are separate)
    48  .IP \(bu 2
    49  Binary size
    50  .IP \(bu 2
    51  Potential skew between multiple libpod versions operating on the same storage can cause problems
    52  
    53  .RE
    54  
    55  .SH Making the choice
    56  .PP
    57  A good question to ask first is: Do you want users to be able to use \fB\fCpodman\fR to manipulate the containers created by your project?
    58  If so, that makes it more likely that you want to run \fB\fCpodman\fR as a subprocess.  If you want a separate image store and a fundamentally
    59  different experience; if what you're doing with containers is quite different from those created by the \fB\fCpodman\fR CLI,
    60  that may drive you towards vendoring.