Go to file
W. Trevor King db388b1949 Makefile: Respect GOBIN
And use 'go env GOBIN' to detect the user's existing preference.  From
[1]:

> The bin directory holds compiled commands.  Each command is named
> for its source directory, but only the final element, not the entire
> path.  That is, the command with source in DIR/src/foo/quux is
> installed into DIR/bin/quux, not DIR/bin/foo/quux.  The "foo/"
> prefix is stripped so that you can add DIR/bin to your PATH to get
> at the installed commands.  If the GOBIN environment variable is
> set, commands are installed to the directory it names instead of
> DIR/bin.  GOBIN must be an absolute path.
> ...
> Go searches each directory listed in GOPATH to find source code, but
> new packages are always downloaded into the first directory in the
> list.

So if GOBIN is set, it will be non-empty, and we can use $(GOBIN)/...

If GOBIN is unset, 'go env GOBIN' will return an empty string (as it
does on Travis [2]).  In that case, I'm assuming that the package in
question is in the first directory in GOPATH and using the new
FIRST_GOPATH (firstword and subst are documented in [3]).  That's
probably fairly safe, since our previous GOPATH handling assumed it
only contained a single path, and nobody was complaining about that.

Using ?= allows us to skip the 'dirname' call if we end up not needing
GOPKGBASEDIR [4] (e.g. for the 'help' target).  The recursive
expansion could cause an issue if the result of the shell expansions
included a '$', but those seem unlikely in GOPKGBASEDIR, GOMD2MAN, or
the manpage paths.  I haven't used ?= for GOBIN, because we'll always
need the expanded value for the if check.

Using GOMD2MAN allows us to collapse old ||-based recipe into a less
confusing invocation.  And using a static pattern rule [5] for
$(MANPAGES) lets us write a single rule to handle both section 1 and
section 5.

While I was updating the GOPATH handling, I moved .gopathok from the
possibly-shared $(GOPATH)/.gopathok to the
definitely-specific-to-this-project .gopathok.  That may cause some
issues if you rebuild after changing your GOPATH without calling
'clean', but I don't expect folks to change their GOPATH frequently.
And the old approach would fail if different consumers were also using
the same flag path to mean something else (as CRI-O does [6]).

As part of cleaning up .gopathok, I've also collapsed clean's rm calls
into a single invocation.  That will give us the same results with
less process setup/teardown penalties.

[1]: https://golang.org/cmd/go/#hdr-GOPATH_environment_variable
[2]: https://travis-ci.org/projectatomic/libpod/jobs/379345071#L459
[3]: https://www.gnu.org/software/make/manual/html_node/Text-Functions.html
[4]: https://www.gnu.org/software/make/manual/html_node/Setting.html
[5]: https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
[6]: https://github.com/kubernetes-incubator/cri-o/blob/v1.10.1/Makefile#L62

Signed-off-by: W. Trevor King <wking@tremily.us>

Closes: 
Approved by: mheon
2018-05-16 17:31:55 +00:00
2018-05-14 13:30:39 +00:00
2018-05-15 17:08:10 +00:00
2018-05-15 17:35:11 +00:00
2018-05-15 17:08:10 +00:00
2017-11-01 11:24:59 -04:00
2018-05-11 13:21:37 -04:00
2018-04-27 14:11:13 +00:00
2018-05-04 17:15:55 +00:00
2018-03-22 13:47:28 +00:00
2018-05-15 17:08:10 +00:00
2018-05-11 13:20:57 -04:00
2018-05-15 17:35:11 +00:00
2018-01-18 07:01:48 -05:00
2018-02-11 10:21:46 +00:00
2018-05-14 13:30:39 +00:00
2017-11-01 11:01:27 -04:00
2018-05-16 17:31:55 +00:00
2018-05-15 17:35:11 +00:00
2017-11-01 11:24:59 -04:00
2018-03-16 13:55:49 +00:00
2017-11-17 02:07:18 +00:00

PODMAN logo

libpod - library for running OCI-based containers in Pods

Status: Active Development

What is the scope of this project?

libpod provides a library for applications looking to use the Container Pod concept popularized by Kubernetes. libpod also contains a tool called podman for managing Pods, Containers, and Container Images.

At a high level, the scope of libpod and podman is the following:

  • Support multiple image formats including the existing Docker/OCI image formats.
  • Support for multiple means to download images including trust & image verification.
  • Container image management (managing image layers, overlay filesystems, etc).
  • Full management of container lifecycle
  • Support for pods to manage groups of containers together
  • Resource isolation of containers and pods.

What is not in scope for this project?

  • Signing and pushing images to various image storages. See Skopeo.
  • Container Runtimes daemons for working with Kubernetes CRIs. See CRI-O. We are working to integrate libpod into CRI-O to share containers and backend code with Podman.

OCI Projects Plans

The plan is to use OCI projects and best of breed libraries for different aspects:

  • Runtime: runc (or any OCI compliant runtime) and oci runtime tools to generate the spec
  • Images: Image management using containers/image
  • Storage: Container and image storage is managed by containers/storage
  • Networking: Networking support through use of CNI
  • Builds: Builds are supported via Buildah.
  • Conmon: Conmon is a tool for monitoring OCI runtimes. It is part of the CRI-O package

Podman Information for Developers

Installation notes Information on how to install Podman in your environment.

OCI Hooks Support Information on how Podman configures OCI Hooks to run when launching a container.

Podman Commands A list of the Podman commands with links to their man pages and in many cases videos showing the commands in use.

Podman Usage Transfer Useful information for ops and dev transfer as it relates to infrastructure that utilizes Podman. This page includes tables showing Docker commands and their Podman equivalent commands.

Podman API Documentation on the Podman API using Varlink.

Tutorials Tutorials on using Podman.

Contributing Information about contributing to this project.

Current Roadmap

  1. Varlink API for Podman
  2. Integrate libpod into CRI-O to replace its existing container management backend
  3. Pod commands for Podman
  4. Rootless containers
  5. Support for cleaning up containers via post-run hooks
Description
Podman: A tool for managing OCI containers and pods.
Readme Apache-2.0 283 MiB
Languages
Go 81.2%
Shell 13.7%
Perl 2%
Python 1.3%
PowerShell 0.8%
Other 0.9%