containers
/
podman
mirror of https://github.com/containers/podman.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add api link to tutorials 

We recently moved the "How to use libpod for custom/derivative projects" page to
the docs/tutorials directory.  This adds a link to the README.md there so it can
be more easily found and adds a logo to the tutorial itself.

Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
This commit is contained in:
TomSweeneyRedHat 2019-10-02 10:25:38 -04:00
parent 257a985f5a
commit 5f932fa441
2 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/tutorials/README.md
View File

@ -19,3 +19,7 @@ Special setup for running the Podman remote client on a Mac and connecting to Po
**[Remote Client](remote_client.md)**
A brief how-to on using the Podman remote-client.
**[How to use libpod for custom/derivative projects](podman-derivative-api.md)**
How the libpod API can be used within your own project.

4
docs/tutorials/podman-derivative-api.md
View File

@ -1,3 +1,5 @@
![PODMAN logo](../../logo/podman-logo-source.svg)
# How to use libpod for custom/derivative projects
libpod today is a Golang library and a CLI. The choice of interface you make has advantages and disadvantages.
@ -41,4 +43,4 @@ Making the choice
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?
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
different experience; if what you're doing with containers is quite different from those created by the `podman` CLI,
that may drive you towards vendoring.
that may drive you towards vendoring.