feat: Read from an .env file

[pythoninthegrass]

Per https://github.com/MightyMoud/sidekick/issues/16#issuecomment-2368041034, this feature would simplify the initial deployment of sidekick with future capabilities such as IP_ADDRESS being a comma-separated list for multiple servers not being a terrible stretch.

Goal

Read from an .env file in the working directory instead of manually inputting details.

Implementation

Modify init.go to check for an .env file and if it's not found or values are missing, prompt the user for outstanding configuration items.

[MightyMoud]

Hey @pythoninthegrass,

Thanks for doing this work. I appreciate every contribution. Currently Sidekick init command will actually add the config per system level as I mentioned previously. Now with this change where would that .env file be? it wouldn't be inside of the project folder cus it's not a project specific config.

The whole idea behind Sidekick is to host as many side projects on one VPS as you can. If you get enough traction with any of them, easily scale up your VPS and move on. But that requires a global config for your VPS; hence the init command will make a config file per system and reuse that later on. Taking those values from an .env file in the current directory is won't work in the current model. I do like the idea of taking info from a file at some point, but where would that file be? Does it add value to ask the user to do this before running the command especially knowing it's a global setting? why would we take those values from the that file, whatever it is, then move the same values to sidekick config folder? Maybe taking info from a file is more suited to the launch command as it's project based.

One last thing is that I would like to push the interactive model to its limits first. Many CLIs are not built like that which is a shame tbh. There will be a limit for sure. However for the initial setup the dialogue is a perfect fit. Also don't forget that in all cases we need the user to approve the VPS's public key - this change is coming soon and is on master branch. I'm making a release today maybe.

Hope it all makes sense. Thanks for your contribution again

[pythoninthegrass]

A global config makes sense. The way that I've been using env files is per repo. Once it's been pushed to the VPS, then of course it would be added to the global config so there's some element of duplication.

With that said, CLIs / TUIs are great, but not scalable. An env file is useful because it could override the global and be changed at any time (e.g., IP or ssh key changes -> config gets overridden.)

With the changes being proposed, you can do either -- interactive or noninteractive deployments. Couple the latter with deployment platforms or CI/CD and that makes sidekick a lot more useful than one-shot manual use cases.

---

From: Mahmoud Mousa @.> Sent: Tuesday, September 24, 2024 4:57:50 AM To: MightyMoud/sidekick @.> Cc: pythoninthegrass @.>; Mention @.> Subject: Re: [MightyMoud/sidekick] feat: Read from an .env file (Issue #17)

Hey @pythoninthegrasshttps://github.com/pythoninthegrass,

Thanks for doing this work. I appreciate every contribution. Currently Sidekick init command will actually add the config per system level as I mentioned previously. Now with this change where would that .env file be? it wouldn't be inside of the project folder cus it's not a project specific config.

The whole idea behind Sidekick is to host as many side projects on one VPS as you can. If you get enough traction with any of them, easily scale up your VPS and move on. But that requires a global config for your VPS; hence the init command will make a config file per system and reuse that later on. Taking those values from an .env file in the current directory is won't work in the current model. I do like the idea of taking info from a file at some point, but where would that file be? Does it add value to ask the user to do this before running the command especially knowing it's a global setting? why would we take those values from the that file, whatever it is, then move the same values to sidekick config folder? Maybe taking info from a file is more suited to the launch command as it's project based.

One last thing is that I would like to push the interactive model to its limits first. Many CLIs are not built like that which is a shame tbh. There will be a limit for sure. However for the initial setup the dialogue is a perfect fit. Also don't forget that in all cases we need the user to approve the VPS's public key - this change is coming soon and is on master branch. I'm making a release today maybe.

Hope it all makes sense. Thanks for your contribution again

— Reply to this email directly, view it on GitHubhttps://github.com/MightyMoud/sidekick/issues/17#issuecomment-2370821087, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA7ILP5GP7TJVL5HG5ZYVDDZYEZR5AVCNFSM6AAAAABOWNQ4XKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZQHAZDCMBYG4. You are receiving this because you were mentioned.Message ID: @.***>

[MightyMoud]

I gave this some thought. I think we can do flags instead to pass the values in. A flag for serverAddress and another for email then they would be saved in the global config. You can override the serverAddress to setup another machine - however, you will only be able to deploy to one machine. Multi machine needs more thinking and will come later. You can use this as a hack for now.

I am also thinking we need to add a globalConfig command to set the default values of those too. So you can run sidekick globalConfig --serverAddress=xxx.xxx.xx.xx email=xx@example.com to set the default values then running the init command would be a one shot. But we need to add another -y flag to skip the host key validation prompt.

Lots of work to do hahhaha

[pythoninthegrass]

I like it. One thing to keep in mind is CLI flags / subcommands are normally all lowercase by convention. So internally it'd be globalConfig while the user would type sidekick globalconfig.

Picking whether it's a subcommand or flag is a little less straightforward but I think it'd make for a better flag like -g or --globalconfig.

---

From: Mahmoud Mousa @.> Sent: Wednesday, September 25, 2024 3:43:56 AM To: MightyMoud/sidekick @.> Cc: pythoninthegrass @.>; Mention @.> Subject: Re: [MightyMoud/sidekick] feat: Read from an .env file (Issue #17)

I gave this some thought. I think we can do flags instead to pass the values in. A flag for serverAddress and another for email then they would be saved in the global config. You can override the serverAddress to setup another machine - however, you will only be able to deploy to one machine. Multi machine needs more thinking and will come later. You can use this as a hack for now.

I am also thinking we need to add a globalConfig command to set the default values of those too. So you can run sidekick globalConfig --serverAddress=xxx.xxx.xx.xx @.*** to set the default values then running the init command would be a one shot. But we need to add another -y flag to skip the host key validation prompt.

Lots of work to do hahhaha

— Reply to this email directly, view it on GitHubhttps://github.com/MightyMoud/sidekick/issues/17#issuecomment-2373445965, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA7ILP53SUVFOKSLWDV4ZFDZYJZUZAVCNFSM6AAAAABOWNQ4XKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZTGQ2DKOJWGU. You are receiving this because you were mentioned.Message ID: @.***>

[gedw99]

https://github.com/knadh/koanf is what I use.

But just having cli flags is a huge improvement, so happy with just that.

It would really help if the cli flags at global level can specify a json out, so we can also get a parsable result from a cli command.

[MightyMoud]

@pythoninthegrass Cool, I'll start working on that soon. Been busy deploying a docs site for Sidekick. I think I need more clarity and space to communicate things better.

As for flags vs command, I was thinking flags you can pass to init or a separate command you can run before running init called globalconfig so you can choose either really depends on your use. Meaning you can set the global config at other times too.

[MightyMoud]

@gedw99 interesting! I chose Viper by default. Will have a closer look at koanf and see what is the difference. Let's discuss the JSON out in the other issue

[MightyMoud]

@pythoninthegrass I just finished the work on the flags for init command you will be able to run this sidekick init --server=139.59.224.40 --email=ma@ma.com or short version sidekick init -s=xxxxx -e=xxxx on next release.

Also after some thinking I'm holding back on the globalconfig command... I don't see the use for doing this separately from just passing the flag. If that is something you need in your workflow let me know. I'll add this to the docs after release.

[pythoninthegrass]

Appreciate you listening to feedback! That looks like a happy medium!

I just wrapped up a project so will have more time to work on the idempotency component if you're still interested.

[MightyMoud]

Whenever you have time dude. I want that change in before next release. So I'll smash other things first for now. If you couldn't find time I'll work on after those things