podman

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.
61