alexhudson / stowage Goto Github PK

As a developer, I would like to be able to distribute my specfile with a Docker image itself, so that I don't need to host a specfile or repo, and end users can install the command easily.

Implementation issues:

It might be possible to use labels for this, but I'm not sure how much data can be stored within them. It could also be possible to insert the file into the image in some well-known location, but that's a bit esoteric and not very dockerish.

There's also the issue of how to define this and insert it. Since images are immutable, the specfile needs to be included as part of the build - we want a nice experience for doing this, whichever implementation choice.

When docker starts running a command that isn't available locally, it will pull the image and start giving us output. We really want to block that - the point of having these wrappers is that you only get the output from the tool.

This means we may need to simply fail to run if we can't fetch the image.

As a developer, I want to be able to list environment variables in my command specification files, so that stowage knows which environment variables to ask Docker to pick up.

As a developer, I want to be able to set a URL that hosts my Docker specfile so that I can offer a simple install process without having to set up a repo for other users to user.

The wrapper automatically passes arguments through to the runtime container, but in run mode it just drops them on the floor. Both should work the same way.

As a user, I want much better checking on errors so that when stuff goes wrong stowage gives me some useful feedback, so that I can correct problems and/or report bugs.

Ideally we want to stop spitting panics unless something really weird happens, because the tracebacks aren't useful.

There are some things which are going to be difficult to test, but at least getting some of the core logic for finding / deciding things covered would be great.

... so that I can ship JSON descriptions of tools in repo and run them like utilities as well 👍

I don't know if this makes sense, because I'm not actually a user myself, but I don't see why this same approach (or a similar one) wouldn't work on Windows.

It would be nice to get a patch to support this. In principle, we probably only need to look at how the wrappers install / operate, most of this is generic otherwise.

The py prototype of stowage allowed you to override params on the command line, --command being the most useful.

We should have this in the Golang version too.

As a developer, I would like to be able to share stow definitions so that other developers can easily discover and install commands I've created, so that I don't need to maintain separate documentation which will inevitably go out of date.

Ideally, this would function a bit like homebrew. E.g. I've created a command "files-push" which is used to put binary output into S3. I want to share "files-push" with others. I have a files-push.json document.

$ stowage repo-list
No repositories configured.
$ stowage repo-create shared-dev-tools
Repo 'shared-dev-tools' created.
$ stowage repo-list
shared-dev-tools  local
$ stowage repo-location shared-dev-tools
/usr/local/some/path/shared-dev-tools.json

.. will create a local "repository" file which is initially empty. I can then add my new command:

$ stowage repo-update shared-dev-tools ./files-push.json
Added new command: files-push

Initially, my stowage doesn't actually follow any repos until I create one, but I can also add a URI:

$ stowage repo-list
No repositories configured.
$ stowage repo-add http://example.com/stowage/my-repo
Repo 'my-repo' added.
$ stowage repo-list
my-repo http://example.com/stowage/my-repo

Either way, if I create or add a repo, I can do a very basic text search to find stuff, and then install it as I would expect:

$ stowage search files
shared-dev-tools:files-push    A basic system for pushing binaries to S3
$ stowage install shared-dev-tools:files-push
$ which files-push
/usr/local/bin/files-push

On Linux, using the stowage container to manage the local system works fine - however, on MacOS, it doesn't appear to work at all.

The main problem here is that /usr/local cannot be bound into the container; it's not on the list of volumes allowed by default, and you also can't configure it.

In theory, we could manage an area under /User easily, however that would still need some manual work to get $PATH to be correct.

Not totally sure this issue is worth solving as having the binary locally available is fine, and we can make this available via homebrew.