#62 config changes for easier setup/development

Closed
smichel17 wants to merge 0 commits from deleted into fr33domlover/master

This way, someone can just build and run, and the changes they make to the state or config won't be added if they want to make a commit and push.

I'm confident that we should add the entries to .gitignore and add the state/ folder. I'm not confident that we should delete the default-state folder (ie, maybe we should ship both). Thoughts?

This way, someone can just build and run, and the changes they make to the state or config won't be added if they want to make a commit and push. I'm confident that we should add the entries to .gitignore and add the state/ folder. I'm not confident that we should delete the default-state folder (ie, maybe we should ship both). Thoughts?
fr33domlover commented 7 years ago
Owner

Hmmm I know what you mean but I made things the way they are for a reason, let's try to find a good solution together.

  1. state-default exists so that you have a copy of the initial state without by mistake the initial state overwriting the real state. I had it as just state earlier but it caused issues so I felt in practice it's better and safer to have state-default
  2. Config.hs must be able to receive changes, the default values etc., that's why it isn't in the gitignore. If you want, you can locally add it to your local copy's gitignore (iirc?) but I'm not sure I want it there in the upstream copy

The mess comes from the Haskell tradition of typed config values edited right in the code. I know the situation isn't amazing and maybe we should have some sort of blank "user config file" whose data is merged with the default Config.hs, you're welcome to try that path.

Or just leave it for later ^_^

Hmmm I know what you mean but I made things the way they are for a reason, let's try to find a good solution together. 1. `state-default` exists so that you have a copy of the initial state without by mistake the initial state overwriting the real state. I had it as just `state` earlier but it caused issues so I felt in practice it's better and safer to have `state-default` 2. `Config.hs` must be able to receive changes, the default values etc., that's why it isn't in the gitignore. If you want, you can locally add it to your local copy's gitignore (iirc?) but I'm not sure I want it there in the upstream copy The mess comes from the Haskell tradition of typed config values edited right in the code. I know the situation isn't amazing and maybe we should have some sort of blank "user config file" whose data is merged with the default `Config.hs`, you're welcome to try that path. Or just leave it for later ^_^
smichel17 commented 6 years ago
Poster

The way I figured it was, if I clone funbot so I can run my own instance, I'm going to need to change the config. Then, maybe I make some local changes and want to send a patch upstream. It is explicitly unwanted, that I'll send my config changes in the patch, therefore the config should be in the .gitignore (but still in the repo!). The exception is if I'm changing the defaults, but I think that case is rare and explicit enough that it's okay to manually override the gitignore and add the changes.

The way I figured it was, if I clone funbot so I can run my own instance, I'm going to need to change the config. Then, maybe I make some local changes and want to send a patch upstream. It is explicitly unwanted, that I'll send my config changes in the patch, therefore the config should be in the .gitignore (but still in the repo!). The exception is if I'm changing the defaults, but I think that case is rare and explicit enough that it's okay to manually override the gitignore and add the changes.
chreekat commented 6 years ago

"Have the file in the repo and in .gitignore" is something I keep thinking works, too -- but it doesn't. Once a file exists in the repo, .gitignore is irrelevant. You might need to try something different. :)

"Have the file in the repo *and* in .gitignore" is something I keep thinking works, too -- but it doesn't. Once a file exists in the repo, .gitignore is irrelevant. You might need to try something different. :)
smichel17 commented 6 years ago
Poster

This particular MR seems like it is going nowhere, so I'm going to close it.

This particular MR seems like it is going nowhere, so I'm going to close it.
Please reopen this pull request to perform merge operation.
Sign in to join this conversation.
No Milestone
No assignee
3 Participants
Loading...
Cancel
Save
There is no content yet.