Better settings parsing and pip installation handling

[b-rowan]

Hopefully a better solution to settings parsing than #105, uses platformdirs to find device specific directories where possible. Will also log a warning about missing settings file, but will still check in project root for development.

Also moved main.py to __main__.py for better pip installation support, so it can be run with python -m goosebit.

Fixes: #103

[easybe]

And of course some nagging about the commit messages. I appreciate that they now contain more information. But, reading them in the console is not that great:

That is why one should break the lines, as explained here. A common guide line is 50 characters for the subject and 72 for the body. Pro tip: Editors can help you with that.

So, your commit message I would change to something like this:

Check multiple places for settings file

Also, rename `settings.yaml` to `goosebit.yaml` to make it
distinguishable from other files.

The user can now pass `GOOSEBIT_SETTINGS` to customize settings
location, as well as gooseBit auto checking `/etc/goosebit.yaml`, the
root of the project directory, and the current working directory when it
is run. This should allow for more optionality when loading settings
files.

Fixes: #103

[b-rowan]

And of course some nagging about the commit messages. I appreciate that they now contain more information. But, reading them in the console is not that great:

That is why one should break the lines, as explained here. A common guide line is 50 characters for the subject and 72 for the body. Pro tip: Editors can help you with that.

So, your commit message I would change to something like this:

Check multiple places for settings file



Also, rename settings.yaml to `goosebit.yaml` to make it distinguishable

from other files.



Use can now pass `GOOSEBIT_SETTINGS` to customize settings location, as

well as gooseBit auto checking `/etc/goosebit.yaml`, the root of the

project directory, and the current working directory when it is run.

This should allow for more optionality when loading settings files.

    

Fixes: #103

I wonder if this is a good case for pre-commit?

[easybe]

And of course some nagging about the commit messages. I appreciate that they now contain more information. But, reading them in the console is not that great:

That is why one should break the lines, as explained here. A common guide line is 50 characters for the subject and 72 for the body. Pro tip: Editors can help you with that.
So, your commit message I would change to something like this:

Check multiple places for settings file



Also, rename settings.yaml to `goosebit.yaml` to make it distinguishable

from other files.



Use can now pass `GOOSEBIT_SETTINGS` to customize settings location, as

well as gooseBit auto checking `/etc/goosebit.yaml`, the root of the

project directory, and the current working directory when it is run.

This should allow for more optionality when loading settings files.

    

Fixes: #103

I wonder if this is a good case for pre-commit?

There is https://github.com/jorisroovers/gitlint

[b-rowan]

And of course some nagging about the commit messages. I appreciate that they now contain more information. But, reading them in the console is not that great:

That is why one should break the lines, as explained here. A common guide line is 50 characters for the subject and 72 for the body. Pro tip: Editors can help you with that.
So, your commit message I would change to something like this:

Check multiple places for settings file



Also, rename settings.yaml to `goosebit.yaml` to make it distinguishable

from other files.



Use can now pass `GOOSEBIT_SETTINGS` to customize settings location, as

well as gooseBit auto checking `/etc/goosebit.yaml`, the root of the

project directory, and the current working directory when it is run.

This should allow for more optionality when loading settings files.

    

Fixes: #103

I wonder if this is a good case for pre-commit?

There is https://github.com/jorisroovers/gitlint

#110

[easybe]

I'll want to test this...

[easybe]

And I would squash the last commit. No need for intermediate (broken) versions.

[b-rowan]

And I would squash the last commit. No need for intermediate (broken) versions.

Will do, just give me a bit.

[easybe]

This is a great improvement, thanks!