Add a dockerized version

[luilver]

Before submitting a pull request, please make sure the following is done:

• Fork the repository and create your branch from master.
• If you've added code that should be tested, add tests!
• Ensure the test suite passes.
• Lint your code with ShellCheck.
• Include a human-readable description of what the pull request is trying to accomplish.
• Steps for the reviewer(s) on how they can manually QA the changes.
• Have a fixes #XX reference to the issue that this pull request fixes.

[inkarkat]

I don't understand the motivation for this. The todo.txt file seems to be inside the container, and therefore its lifetime is bound to the container's lifetime. Lose the container, lose your tasks; not useful.
Mounting the file from an external file system makes more sense, but why would I need to run todo.sh in a container? Its prerequisites are so tiny; any system that has Docker should be able to run todo.sh as well?!

[luilver]

Motivation

I don't understand the motivation for this.

I’ve never thought about this, my only motivation was naively running into a persistent container. Now that you mention it, I took a time for thinking and here you go some:

Portability: Lets say my persistent continer is running remotely and I would like to get the same todotxt environment all over my devices/oses: macos laptop, windows desktop, ubuntu raspberri pi, etc. With the plus of no dependency hell (which is also one of my developer’s life purposes).

Ease of Deployment: Back in the days I created my own script for this: ssh into my remote host, and sync with my local todo.txt folder. The problem with that was that every other device had to sync with the remote host. What if instead of syncing I maintian a single source of truth that could be loaded no matter my device?

Scalability: This is something Ive also never thought but what if I would like to distribute my todotxt-s with my team?

I could continue but I believe its clear my main motivation was containerization per se which, by the way, its something nobody asked as a feature before.

The todo.txt file seems to be inside the container, and therefore its lifetime is bound to the container's lifetime. Lose the container, lose your tasks; not useful.

You might be right, but that’s something solved with docker volumes.

Mounting the file from an external file system makes more sense, but why would I need to run todo.sh in a container? Its prerequisites are so tiny; any system that has Docker should be able to run todo.sh as well?!

You’re right, I don’t. The point is not running todo.sh in a container but running all the process arount it.

I’m a lazy developer that hates to install the same software over multiple devices/oses. Even a tiny app like todo.txt might behave differently depending on the system it’s running on.

Foremost motivation I dont want to re-(install/configure) it every time I reinstall any of my devices/oses (and believe me it happens often).

Another why not: What if I want that incredibly useful piece of software as part of a larger ecosystem or devops platform for automation.

Final thoughts

Let’s say you work with a remote team, and everyone uses todo.txt for managing their personal tasks. Rather than requiring everyone to configure their environment or ensure they have the correct dependencies, you could share a Docker image that contains todo.txt along with any relevant configuration and remote file system for the data. Team members just need to run docker run on their systems, and they’re up and running instantly—no installation or setup headaches. Additionally, you could mount the task file as a volume, ensuring everyone’s tasks are in sync across different systems and environments.

Even tho I may agree with you that while todo.txt is small, containerization brings a host of advantages like portability, ease of sharing, isolation, and integration with larger systems and workflows. The overhead is minimal, and for many users or teams, the trade-off for these benefits is worth it—especially when compared to the simplicity of setting up and managing a containerized environment.

I might understand it’s a software that wasn’t thought for this purpose but at the end of the day who decides what’s the best use for a software: Their users.

In the past I’ve considered to contribute with this project. Now I believe I have another motivation for doing so. With all that said, let me add some tests to that Dockerfile.

Thank you for your really good questions.

[inkarkat]

With your detailed explanation, it makes a bit more sense ;-)

For synchronization or sharing tasks among the team, the usual approach is a Dropbox / Google Drive / Nextcloud etc. folder as $TODO_DIR. If you have existing Docker (or even Kubernetes) infrastructure, you could certainly use that to share a volume containing todo.txt, but it would be a bit overkill for this use case.

But your main point is the portability and ease of installation. My first thoughts on that go towards solutions like Snap or Flatpak, which offer app stores and single-click installations. Of course, these also use containerization under the hood, and Docker can provide the encapsulation, too.

Going with Docker, I think users would expect to simply docker pull todotxt-cli:latest and then run it. The build and upload of the Docker image should be done by the maintainers (i.e. us, via extensions to the GitHub workflow), not the end users. And as a user, I'd expect more documentation on how to use the image, set up persistent volumes for the todo.txt file, etc. This pull request is a good start, but far from complete IMHO.

Before going further, it would be good to first have more feedback from the community; i.e. whether there's demand for Docker (or rather Snap / Flatpak / whatever).