🚀 Feature: make cli "docker run"nable

[dweipert-3138720606]

🔖 Feature description

Being able to run the cli as a docker container would be great.

I've found the image on Docker Hub here: https://hub.docker.com/r/appwrite/cli Is that just an old remnant?

And the old Pull Request https://github.com/appwrite/sdk-for-cli/pull/2 that looked like a good start 4 years ago

Since appwrite itself is already neatly spread out over several containers in the official docker-compose.yml it would feel natural to have the cli as a service as well. I guess that was the reasoning 4 years ago as well:)

Would be happy to see that considered again.

🎤 Pitch

I want to use it in the docker-compose.yml as a service so I can do docker-compose exec appwrite-cli users list for example.

I don't want to install an extra binary or npm to install it globally because I like my dependencies bundled with the project they belong to.

👀 Have you spent some time to check if this issue has been raised before?

• [X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• [X] I have read the Code of Conduct

[christyjacob4]

@DRogueRonin Thanks for bringing this up again.

Our initial idea with the appwrite/sdk-for-cli 4 years ago was to write it in php, just like Appwrite. However we realised not everyone would have php installed on their machines and we wanted to ship the CLI in a way that that would remove this dependency on php.

Hence we chose to ship the CLI as a docker image and adding the appwrite binary to the $PATH in a way that it invokes the docker image.

During this phase we faced two major issues

1. It was harder to get more interactive features into the CLI like select, checkboxes , multi-select etc. as we didn't find a lot of libraries that did it well in php
2. Docker was still a dependency for the cli which some users complained about

Hence we decided to pivot and switch to Deno as it would allow us to build binaries for different operating systems. Deno being relatively new 2 years ago was still missing some of the cli libraries and tools. So we ultimately went with node.

Today you can install the CLI from source, using npm, homebrew or using the binaries. We didn't feel the need to go back to docker again and introduce this dependency again.

That said, it shouldn't be hard to implement. Are there any strong reasons we should support it?

[dweipert-3138720606]

Thanks for the explanation!

I understand that having docker as a dependency could make the CLI unusable in some environments, so having a standalone binary now is great for sure in that regard.

I don't know whether my reasons would be strong reasons, but those are the only ones I have right now. Having the CLI accessible from the same folder only where I setup Appwrite is just something I like to do, to keep all software related to a service in the same place. So it's easier to manage/edit/delete them without forgetting something. At least for me.

That being said I guess it's really not that hard to implement and I could just build a Dockerfile that installs the CLI and add that as CMD directive. Then add that to my docker-compose.yml as a service. That way I can just run docker-compose exec appwrite-cli users list then for example.

Since it's a standalone binary already, docker would just be a wrapper around it to make it usable as a service in a compose-file, so no new dependency for end-users would be introduced, instead it would be just an additional way to use the CLI for people like me that have a use-case for it.

The appwrite/sdk-for-cli could add a Dockerfile and publish that image to Docker Hub under appwrite/cli again. This way the abandoned image could be revived again as well:)

[christyjacob4]

@DRogueRonin thanks for sharing more context. I can see its benefits for sure. What I'll do is bring it up in our discord community during our community updates tmro as well as run it by the team to see what they think and then update you.

Thanks a lot 😄

[stnguyen90]

@DRogueRonin thanks for bringing this up! 🙏🏼 I don't think this would be a good idea because it would make some of the use cases for using the CLI more difficult and confusing.

First, you would need to mount in the appwrite.json, functions, and prefs.json, making the docker command longer and more difficult.

My second point relates to

Having the CLI accessible from the same folder only where I setup Appwrite is just something I like to do

The CLI is a client tool for managing Appwrite, but it isn't required to be used/run on the server where Appwrite is running. I actually discourage using the CLI on the Appwrite server and encourage using it alongside client apps (including the appwrite.json and functions with the source code of the client app).

[dweipert-3138720606]

I understand that reasoning. I think my specific use-case for the CLI shaped the idea that it'd be useful to have it runnable on the server.

What I wanted to do with the CLI is set up a script that creates and configures a project in appwrite the way my "frontend" project needs it. So having Appwrite as an auth/etc backend for my project.

This project also uses docker-compose, so I'd set the appwrite-cli as a service in that project's docker-compose and run the script that way. Make it connect to an arbitrary Appwrite-instance set in the project's .env file etc.

That thought got lost in my head along the way of my previous use-case explanation, I believe. I didn't spell out that it's concering another project that I want to connect to appwrite and got myself a bit confused in the process of explaining it.

I hope my explanation here is understandable and not too confusing. I'm having a bit of trouble finding the correct words. I can rephrase or clarify if needed.

But I guess for my use-case that's not really the way of doing things, since Appwrite can do multi-tenancy and house multiple projects. Or maybe the CLI is just not the tool for that use-case.

[stnguyen90]

@DRogueRonin,

It does sound like you're using the CLI with your client project, which is the right approach. I'm just really concerned that using the CLI through docker would be complicated. To see what I mean, you can create a docker image with the CLI and try using it.

Another alternative to could be to use npx to run the CLI: