#67
We know it is convenient. :)

Oh I hadn't seen that I wasn't the first !

Afterwards, from a personal point of view, I don't find that adding a Dockerfile to a project makes the project very complex but I agree like the creator that a Dockerfile is not a file mandatory for the project and we can easily run one next to the project.

After it's can be a good idea to propose an example of Dockerfile for people who want use a container but this is an other story and so feel free to close this pull request.

If the official image gets on the repo, I'd be interested in building up the functionality to automatically publish images to the official DockerHub registry :)
(In fact, I'd supposed to begin building it up on my unofficial docker image project to keep track this tool' updates in a few days)

Since I had the same thought as @gungun974, I also built a Dockerfile for it: https://git.tacam.de/Lukas/s3s-docker

Would there be something wrong with running the update process in the container itself?

The project is currently structured in such a way that everything that was pushed into the repo is the latest version that is pulled during an installation.

Would there be something wrong with running the update process in the container itself?

The project is currently structured in such a way that everything that was pushed into the repo is the latest version that is pulled during an installation.

For me the way that Docker Image have been designed is like a snapshot of a specific release.

For example s3s:0.1.19 will create a Container with only this version and same for any version.

After it's not the end of the world for a container to auto update himself but I don't think it's the role of the container to update himself. (It's okays to just say to the user when an update is available)

For me to auto update a container is more recommend to use something more specialized like https://hub.docker.com/r/containrrr/watchtower.

I agree with you, but as long as the Dockerimages are not built right here in the project, this sounds like a manual task.
...
Nevermind, it should be easily possible to build something like this to automate this task:
https://github.com/frozenpandaman/s3s/blob/master/s3s.py#L830

Yes it's normal that sound like a manual task but if the idea to have an official "s3s" docker image is accepted.

Like I said and @issei-m said too. We could setup in this project a CI/CD pipeline with Github action to automate the task of creating Docker Images on latest commit or release tags and publishing it on Docker Hub.

I would also love to see an official Docker image, but as mentioned in the pull request linked by @niyari, it is rather not planned :(

Thank you for the PR and discussion! I don't use Docker, honestly am not really all that familiar with it, and do want to keep this repo as absolutely simple as possible (essentially just a single .py file… with two other helper files) and these are the reasons I don't think I want to *officially* support this, in this repo – but if someone is willing to maintain a fork with support, that would be great, and I'm more than happy to link to it!

I personally just run the script manually, but maybe this isn't everyone's use case…

1. Start up s3s on my computer with -r -M
2. Play Splatoon
3. Exit s3s when done playing

To me that's simple enough (and I'm usually on my computer & talking with people while playing) but I do very much understand the desire & need for automation. Docker just feels like it overly complicates things, for me, personally…

My other big concern is that if anything goes wrong, or anyone needs help, I won't be able to give it – I will just have to trust someone else will be able to fix things in a timely manner and provide other users with support. It would be whole different part of the project, practically and conceptually, that would need to be maintained entirely by someone else. Is that not what a fork would be perfect for?

@issei-m has been generously maintaining an image for splatnet2statink here: https://hub.docker.com/r/isseim/splatnet2statink

There are a few other older, related resources linked in the s2s wiki: https://github.com/frozenpandaman/splatnet2statink/wiki/automation#docker

I'm happy to add a guide and/or provide more info for users who are wanting something like this in the s3s wiki. And I'll add the links to https://hub.docker.com/r/isseim/s3s and https://git.tacam.de/Lukas/s3s-docker there now! I didn't know these existed, so thanks!

When it comes to the s3s repo itself, I want to eventually (post-v1.0.0 = when Salmon Run & Tricolor TW are both supported) publish pre-packaged executables/releases (using PyInstaller), like s2s did, so that users even without Python or Git installed can run the program with ease – again, I want this project to be as simple as possible, not only for developers or those familiar with the command line, but for anyone to just download a file and click on it. This is in the "what's coming" section of the readme currently. And building on what s2s did (with @tkgstrator's help), It'd be nice to set up GitHub Actions to automatically build & publish Mac and Windows releases. But that's the most CI/CD I want to officially have running here.

I really appreciate all the discussion! I just want to make sure that everyone is OK & still satisfied if this doesn't get "officially" supported in this repo – but I do officially support someone else maintaining it in a fork or over on Docker Hub and pointing people to there. :) Is that not essentially just as good, as long as someone is dedicated to keeping it up to date? (that person just can't be me because I don't know what I'm doing! sorry!)

And @gungun974, @issei-m, @lunibo or others, let me know what I can best do to support the images you are maintaining.

This is completely a fair feeling @frozenpandaman.

Nobody can't force you to take the charge of supporting something you can't fully understand and maintain it.

However we can maybe transform if @issei-m is okay his https://github.com/issei-m/s3s-docker repo in a sort of official side project that will only create Docker image for "s3s" and you can reference and promote the link on the Readme.md of this repo for those interested in docker.

(If I said that it's because I don't think it's a good idea for the long term to create a fork of this project and every time merge upstream edit.)

I think this is a good compromise between the existence of the Docker Support and you keeping this project simple enough.

Well since in every other case we don't want a direct support of Docker on this project.

I will close this Pull request but this not mean it's the end of this conversation.