erabo/spiegel_podman
1
0
Fork 0
mirror of https://github.com/podman-container-tools/podman.git synced 2026-10-28 08:47:39 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 5

Merge pull request #4169 from TomSweeneyRedHat/dev/tsweeney/tutreadfix2

Browse source 
Add api link to tutorials
This commit is contained in:
OpenShift Merge Robot 2019-10-03 06:37:33 -07:00 • committed by GitHub
commit b32cb4b750
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
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.