lilydjwg/nvchecker

`nvcheck -c`'s default value

Freed-Wu opened this issue · 11 comments

Freed-Wu commented

How about:

When nvchecker.toml exist in current directory, use it as default configuration.

If not, use ~/.config/nvchecker/nvchecker.toml as default configuration.

lilydjwg commented

No. Path-dependent behavior is bad and very confusing. How many Python learners have once named their learning scripts as abc.py, code.py or random.py etc?

Freed-Wu commented

There are many programs using some file in current directory,

such as:

  • clangd use .clangd as first choice, ~/.config/clangd/config.yaml as second choice.
  • gdb use .gdbinit as first choice, ~/.config/gdb/gdbinit as second choice.
  • astyle use .astylerc as first choice, ~/.astylerc as second choice.

Why nvchecker doesn't use nvfecther.toml as first choice, ~/.config/nvchecker/nvchecker.toml as second choice?

lilydjwg commented

They are related to current project. nvchecker doesn't associate to a project.

Freed-Wu commented

I hope I can use nvchecker in the following case:

git clone ssh://aur.archlinux.org/XXX
cd XXX
update.sh
git add -A
git commit -m 'Update'
git push

Where update.sh use nvchecker --logger=json. It is related to current project XXX.

lilydjwg commented

Probably you want to create an issue for nvfetcher instead.

Freed-Wu commented

Sorry, it's a typo. I also use nvfetcher but just in NixOS, not ArchLinux.

Freed-Wu commented

And nvfetcher uses nvfetcher.toml as default config.

lilydjwg commented

Still you can implement your logic for finding config file in your update.sh.

Freed-Wu commented

nvchecker doesn't associate to a project.

But it actually proves that there is a case that nvchecker associate to a project and it is very useful for AUR users. So why not support it?

lilydjwg commented

nvchecker has no intension to work on a per-project basis. It's your wrapper's responsibility to handle that. It would be a breaking change anyway.

Freed-Wu commented

OK, I see.