Allow enabling services with non-standard docker images

[tpetry]

As described in #236 you sometimes want to use non-standard docker images because they have some plugins bundled you may want to use. Especially for PostgreSQL there are a lot of plugins not available in core, the most common is the PostGIS extension.

Instead of simply specifying a simple docker tag in the dialog you can now easily change the base by typing e.g. postgis/postgis:latest. This will also solve the pull request for TimescaleDB as TimescaleDB is just a PostgreSQL extension.

[mattstauffer]

This is super clever and simple. Thanks @tpetry!

[mattstauffer]

@tpetry I just realized--I would love to have a test that covers this. Do you have the time and ability to add one? If not, I'll write it; let me know.

[mattstauffer]

Hm... I tried your exact code (postgis/postgis:latest) there and it didn't work.

I have a sneaking suspicion that the latest checker doesn't acknowledge your code here.

Let me try it with a PostGIS specific tag...

[mattstauffer]

OK, it works with a PostGIS-specific tag.

So we have a one bug. I should've tried it before merging, but as long as we don't document or announce it I think we're fine:

1. latest doesn't resolve according to the provided image, it resolves according to the base image.

Is this, plus the test(s), something you can work on @tpetry?

[mattstauffer]

https://github.com/tighten/takeout/issues/244 https://github.com/tighten/takeout/issues/245

[tpetry]

I am currently very time constrained, i could work on it in a few weeks.

[tpetry]

Kind of strange that the latest tag does not work, i am kind of sure it did. I see that the algorithm was changed 22 hours ago. Maybe my „hack“ for custom images depended on the implementation? Strange.

[mattstauffer]

@tpetry OK, I'll try to get to it.

It's also possible that when you tested it, the tag that was "latest" on Postgres also existed on PostGIS, whereas it doesn't anymore.

[mstaack]

oh neat, using postgis a lot ! thanks @tpetry