search

EdJoPaTo / website-stalker

Track changes on websites via git
GNU Lesser General Public License v2.1
54 stars 6 forks source link

feat(cli): Add cli flag for (optionally) selecting the config file #171

Closed Teufelchen1 closed 1 year ago

Teufelchen1 commented 1 year ago

Hi! 👋

This is an example on how one could add an optional configuration file flag to the cli.

I'm not sure if I nailed the usage of clap - specifying the flag twice (per check and run) feels odd.

This change should not break existing setups - since I do not have one, I could not test that claim.

Teufelchen1 commented 1 year ago

specifying the flag twice (per check and run) feels odd.

this could be done as a global flag and used in all the subcommands.

Neat! I adopted that change.

I'm not sure yet whether I like having a configurable config file path or not. Having it basically means the sites folder path should be configurable too. Currently the folder setup with the website-stalker.yaml and the sites folder is strict and therefore relatively easy to handle with the git integration as there are not so many sideeffects possible. But it's also nice to have more things configurable.

Hm, I see. I might have rushed this and spend too little time thinking of the side-effects of this change. For the moment, closing this PR seems the best action for me. We can always come back later, when we are certain this change is useful and the side effects are acceptable / accounted for.

EdJoPaTo commented 1 year ago

Hm, I see. I might have rushed this and spend too little time thinking of the side-effects of this change. For the moment, closing this PR seems the best action for me. We can always come back later, when we are certain this change is useful and the side effects are acceptable / accounted for.

Guess that's also a benefit of having multiple people thinking about things. There always will be different goals and benefits so I don't think it's a bad thing to suggest things and to start thinking about a topic.

It's the same in this case: I do like the idea of more customisability in general but after thinking about it it does not seem that wise in this case. Thinking about it made it more clear that that's the case for this tool.

Personally I try to start a discussion first before providing a PQ so I get other mindsets involved. Often not via GitHub (depending on the project). Then I try to work on the improvements with higher confidence that they will be merged. That works kinda well for me currently. Maybe that approach also seems helpful to you.

As you suggested I will close this. Feel free to reopen / share thoughts when it feels relevant so we can talk about it.

Thanks again for your thoughts and efforts to improve this tool!