Request: Logical sort for Created column

[chrislong]

The Created column appears to be sorted lexicographically, which doesn't give good results when the values are things like "3 hours", "13 days", and "2 weeks".

I don't know of a way to get docker to output ages in a consistent time unit. Maybe adding the Creation date column would be a good workaround since it might be more easily sorted?

Useful package, though, thanks!

[Silex]

Hum, good idea... I was thinking of having it maybe configurable, because if I add the "Created At" column then my screen is not wide enough to display it all nicely.

Here are the option we have: https://docs.docker.com/engine/reference/commandline/ps/#/formatting

You can test like:

docker ps --format "{{.ID}} {{.CreatedAt}} {{.RunningFor}}"

[Silex]

The configuration would be something like:

(setq docker-containers-columns '(ID CreatedAt RunningFor))

[GPPassos]

@Silex , this workaround didn't work here. Perhaps this variable isn't used anymore?

[Silex]

@GPPassos: this was just an idea of how to implement it, it's not actually implemented yet :-)

I'm currently refactoring docker.el quite a lot, maybe I'll have time to tackle this too, I'll keep you updated.

[gonewest818]

fwiw, you can get raw values for dates and sizes via the docker API. For instance, rather than "docker images" you can

$ curl --unix-socket /var/run/docker.sock http:/v1.24/images/json

which yields

[
    {
        "Containers": -1,
        "Created": 1517253418,
        "Id": "sha256:a040286ca02be32587a8120d503d8d23aa16a5d983e74c9036dca890e446a77d",
        "Labels": {},
        "ParentId": "",
        "RepoDigests": [
            "mesosphere/marathon@sha256:bfb87dd0d8916c4776bee6ca3aee55ad511ac1d86be514273482ec644e6463ac"
        ],
        "RepoTags": [
            "mesosphere/marathon:v1.5.6"
        ],
        "SharedSize": -1,
        "Size": 675450077,
        "VirtualSize": 675450077
    },
    {
        "Containers": -1,
        "Created": 1515572484,
        "Id": "sha256:56d414270ae3ca3b4bd09b8ec7971895360427bb71047c04e9c6313cb22cfcff",
        "Labels": null,
        "ParentId": "",
        "RepoDigests": [
            "zookeeper@sha256:21d59c2458e1b5506ebd2b18d04c9b23eb01760a30638ac63d20966b0df5a4ad"
        ],
        "RepoTags": [
            "zookeeper:3.4.11"
        ],
        "SharedSize": -1,
        "Size": 146158697,
        "VirtualSize": 146158697
    },
    # etc
]

[gonewest818]

Obviously you could build a complete docker-client.el using these REST APIs, but it wouldn't be strictly necessary. You could start by replacing only the reporting commands like docker images, docker ps, etc.

[Silex]

@gonewest818: there was work done in this direction at https://github.com/Silex/docker-api.el

But the thing is, it's quite a lot of work to make it use the API, and if you look at things like magit it does use the command line too, because it's more simple to make it map to the real commands.

Something like docker images -a --filter "dangling=true" is different with the API, so there would need to be translations from expected commands into the API, which could introduce bugs and different experience that from the command line.

[gonewest818]

Two points.

1. Docker has long exposed this REST API and it is common practice to write clients with that API, including the docker command itself, the java bindings, the python bindings, Apache Mesos, and so on. That alone would give me much more confidence that mixing different tools that access the API is viable. If there are differences between the API and the command line tools then those differences are going to be representational (how you refer to things, or how status is reported back to you) and not functional (what functions can be performed, or what those functions do). Because the command line tools don't embed implementations of the functions at all.

2. I think it was really unfortunate that git got to be understood first and foremost as a set of commands you invoke at the command line. Many users (I'll include myself in this category) learn "what commands to type" but fail to remember the exact data model or how it works. In fact, git's data model is rarely expressed in terms other than the commands themselves. This is why magit's "$" transcript is so valuable, because it's a portable representation of what happened.

Docker has a simpler model, and the command syntax isn't used as a shorthand to describe the state of the system in the manner we do with git.

Up to you, ultimately, but this is where I'm coming from.

[Silex]

@gonewest818: interesting points, but there are still things that I don't know straightforwardly how to map over the docker API.

For example, implementing docker run -e FOO=BAR --rm -p 80:80 nginx equivalent... right now I use async-shell-command, do you reckon that would be easy to implement with the API? I guess the flags are just translated and part of the request headers, but then keyboard input and pretty output is unclear to me.

I guess request.el has long-request support and that somehow you can map keyboard input to be sent to that stream...

I'm not against using the API, I'm just afraid it'll be a lot of work :sweat_smile:

[gonewest818]

Quick comment on this. Getting an interactive shell is an excellent case for using docker run -it rather than trying to reinvent it again in elisp. There's nothing more to gain in a custom implementation. Whereas there is clearly (well, or so I think) value in grabbing raw container and image metadata directly from the docker daemon because you can format and print the raw data however you like.

[Silex]

Ok so to talk with docker there would be two paths:

• run docker CMD for most of the commands.
• use the docker api for the containers/images/networks/volumes listing.

I think using two paths is kind of a mistake, as there would need to be configuration for the two apis (the path to /usr/bin/docker binary and /var/run/docker.sock socket). How would that work on OSX/windows? I don't think the socket is exposed under those, so all the docker commands would work but then the listings wouldn't.

For now, I think if all we want to fix is the dates/sizes all we need to do is improve the parsing of what docker returns (parse the MB part etc).

That said, I'm not against the change, it's just that the pros are not really huge and the cons could be very annoying (requiring users to modify their docker config for it to work, etc).

Also, I have so many other issues that have more priority over this, and it's been almost a year I can't take time to tackle them :cry:

[Silex]

:tada:

I pushed two commits which should sort correctly by Created and Size.

Sorry it took me so long but I finally have a bit of time to work on docker.el :smirk: