runlike and the warning its own metadata contradicts

The status section says not to use it, the classifier says stable

The Status section is unusually direct. It says this is very much a work in progress, that many run options are not yet supported but the most commonly used ones are, that pull requests are welcome for anything added or fixed among the bugs the package admittedly has, and then in bold that you probably should not use this in production yet, with the advice to double check that it is actually running what you want it to run. The package metadata, in the same repository, carries the classifier for production stable. Both statements are about the same artifact, and the one a user is most likely to encounter first is the classifier, since it is what an installer and a package listing show.

Both option lists stop in the middle of a line

The two lists that carry the tool's actual specification are the ones that are cut off. The supported block shows six options, and its last entry is the background flag with a description that ends on the word and, with no closing text and no continuation. The unsupported block opens with a blank line and then four entries covering attach, two block-I/O weight flags, a cgroup parent and a container-ID file, before it stops as well. So the boundary between what this tool reconstructs and what it drops, which is the only thing a reader needs from those sections, is exactly the part that is missing. The file offers no count and no date for either list, so there is no way to tell from it whether the truncation is recent.

The no-install route mounts the Docker socket, and suggests an alias

The container route is one command, and it is short enough to copy without reading:

docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
    assaflavie/runlike YOUR-CONTAINER

The socket is how a container talks to the Docker daemon, and holding it is close to holding root on the host: anything with it can start a container with any privileges the daemon allows. The README then goes one step further and suggests adding that whole command to a shell profile as an alias, so that the socket mount becomes something you type every day without seeing it. There is no read-only alternative offered, no warning about what the mount grants, and no note about who can run it. The alias is a convenience, and it is also the step that makes the privilege invisible.

The image installs a published release, not the source beside it

The container file takes a version as a build argument and installs exactly that version from the package index into a virtual environment inside the image, then declares the tool as its entry point. The build file supplies that version by running a small script from the repository to print the current one, and tags the built image with it. So the image is a thin wrapper around an already-published artifact: it cannot contain unreleased code, and a fork that builds its own Dockerfile will faithfully install the upstream release unless somebody remembers to change the argument. The base image is also an unpinned tag rather than a digest, so the layer underneath the tool can change without the tool changing.

Two test runners declared, one invoked

The development dependency group lists two runners, one of them the nose framework at a version whose caret allows only the 1.x line, alongside pytest at a much later version. The build file's test target invokes pytest and nothing else, so one of the two declared runners has no visible use in this repository. The tree also carries a pair of shell scripts whose names suggest capturing fixtures and inspecting them, which lines up with the tool's documented ability to read container inspection output from standard input: the tests are almost certainly driven by recorded inspection payloads rather than by starting containers.

Classifiers for two Python versions the dependency floor forbids

The dependency constraint says Python 3.8 or newer, while the classifier list runs from 3.6 to 3.11. Two of the advertised versions are therefore versions the package says it does not support, which is the kind of thing that matters when something indexes by classifier rather than by constraint. The same file also mixes two packaging styles: the project is declared in the older poetry table, with the tool, the dependencies and the console script, and then a separate project-urls table follows with homepage, issue tracker and source links. That second table belongs to the newer standard, which expects a matching project table above it, and there is not one in the file as it stands.

Publishing treats one specific error as success

The release target chains three things: rebuild the image without cache, push both the floating tag and the version tag, then build and publish the distribution. The publish step pipes its output through a filter that looks for the already-exists error from the index, and if that text appears it prints that the version is already there and carries on; anything else that fails exits non-zero with a message. So the release is safe to re-run, and the way it achieves that is by reading an error string rather than by asking the index first. The same target also guarantees that every release rebuilds the image from scratch, since publishing depends on a push that depends on a cache-free rebuild.

Fourteen months of commits after the last release

The release record is thin and oddly paired: 1.6.0 in late January 2025, then 1.6.1 and 1.6.3 on the same day in February, forty-two minutes apart. The branch took a push on 2026-04-27, so roughly fourteen months of work sit after the newest tag. The version in the packaging file still reads 1.6.3, which means the metadata is honest about where it stopped rather than ahead of itself. Around it the tree holds a second directory for container files beside the root one, a bin directory, the two fixture scripts, a lock file, and a single test module at the root, none of which the README mentions.

Editorial conclusion

runlike fits the person who deployed a container through a configuration manager and now needs the command by hand, which is exactly the gap its opening quote describes. Four things to know before you make it part of a runbook. Read its output rather than executing it blindly, because the file itself warns that many run options are unsupported and that you should check what it produced. Remember that the command it prints is a reconstruction, not the original, so anything it does not model is silently absent from the output. Know that the no-install route mounts the host Docker socket, which is the most privileged thing you can hand a container, and that the README suggests making that a shell alias. And treat the option lists as incomplete: both of them are cut off here, so the supported set is larger and smaller than it looks.

Frequently asked questions

Official sources

1. Issues
2. lavie/runlike on GitHub
3. README
4. Releases