Completion command tries to create configuration file about mangal HOT 8 CLOSED

I decided to create paths whenever they're mentioned so I can be sure that they exist. Maybe I'll change it in the future, but right now it's not really an issue

Sure, no problem. As I said is a design choice and if it reduces the complexity it is totally reasonable.

About the completions, they are missing from the release 3.3.0 and since they are auto-generated by the library my best bet would be to get them straight from the application. At least we'll always be sure they match with the source code, without relying on a manual operation.
I tried setting the MANGAL_CONFIG_PATH variable to a temporary folder and it does work perfectly.

from mangal.

Thank you for opening an issue!

That's interesting... I think this line causes the problem. And not only for completion command but also for any other command

I can handle the case where $HOME is not set and use backup path. Unfortunately, I'm not very familiar with Nix nor isolated environments so I don't know what would be the best choice. Maybe root /? Or maybe using home backup paths is not an option at all?

from mangal.

No problem, thanks for the great application.

The complete trace is the following:

panic: mkdir /home/bertof/.config/mangal/sources: permission denied [recovered]
	panic: close of nil channel

goroutine 1 [running]:
github.com/charmbracelet/bubbletea.(*standardRenderer).kill.func1()
	github.com/charmbracelet/[email protected]/standard_renderer.go:94 +0x25
sync.(*Once).doSlow(0x1a64a00?, 0xc000010018?)
	sync/once.go:68 +0xc2
sync.(*Once).Do(...)
	sync/once.go:59
github.com/charmbracelet/bubbletea.(*standardRenderer).kill(0xc000216240?)
	github.com/charmbracelet/[email protected]/standard_renderer.go:93 +0x9e
github.com/charmbracelet/bubbletea.(*Program).shutdown(0xc000558160, 0x4?)
	github.com/charmbracelet/[email protected]/tea.go:586 +0x52
github.com/charmbracelet/bubbletea.(*Program).StartReturningModel.func3()
	github.com/charmbracelet/[email protected]/tea.go:369 +0x49
panic({0x114a0c0, 0xc000846f90})
	runtime/panic.go:844 +0x258
github.com/samber/lo.must({0x11f99e0, 0xc0008419e0}, {0x0, 0x0, 0x0})
	github.com/samber/[email protected]/errors.go:43 +0x1f4
github.com/samber/lo.Must0(...)
	github.com/samber/[email protected]/errors.go:60
github.com/metafates/mangal/where.mkdir({0xc000041e60, 0x23})
	github.com/metafates/mangal/where/where.go:14 +0x57
github.com/metafates/mangal/where.Sources()
	github.com/metafates/mangal/where/where.go:32 +0x5b
github.com/metafates/mangal/provider.CustomProviders()
	github.com/metafates/mangal/provider/provider.go:56 +0x46
github.com/metafates/mangal/tui.(*statefulBubble).loadSources(0xc000818000)
	github.com/metafates/mangal/tui/bubble.go:216 +0x127
github.com/metafates/mangal/tui.(*statefulBubble).Init(0xc000818000)
	github.com/metafates/mangal/tui/init.go:26 +0x2a5
github.com/charmbracelet/bubbletea.(*Program).StartReturningModel(0xc000558160)
	github.com/charmbracelet/[email protected]/tea.go:400 +0x70a
github.com/charmbracelet/bubbletea.(*Program).Start(...)
	github.com/charmbracelet/[email protected]/tea.go:549
github.com/metafates/mangal/tui.Run(0xc0004fdd46)
	github.com/metafates/mangal/tui/tui.go:29 +0xbf
github.com/metafates/mangal/cmd.glob..func9(0x23e0460?, {0x13560ac?, 0x0?, 0x0?})
	github.com/metafates/mangal/cmd/root.go:63 +0x65
github.com/spf13/cobra.(*Command).execute(0x23e0460, {0xc000032200, 0x0, 0x0})
	github.com/spf13/[email protected]/command.go:872 +0x694
github.com/spf13/cobra.(*Command).ExecuteC(0x23e0460)
	github.com/spf13/[email protected]/command.go:990 +0x3b4
github.com/spf13/cobra.(*Command).Execute(...)
	github.com/spf13/[email protected]/command.go:918
github.com/metafates/mangal/cmd.Execute()
	github.com/metafates/mangal/cmd/root.go:81 +0x5e
main.main()
	github.com/metafates/mangal/main.go:13 +0x4d

So the error is generated in github.com/metafates/mangal/where/where.go:14 when calling github.com/metafates/mangal/where.Sources() from github.com/metafates/mangal/provider.CustomProviders()

So perhaps it could be a good idea to return an empty list of custom providers if the configuration file is missing or the read fails here.

I guess the best solution would be to load the configuration only when it is required to execute the command, i.e. not for version, env and completion.

If you want I can try to make a pull request.

from mangal.

I guess the best solution would be to load the configuration only when it is required to execute the command, i.e. not for version, env and completion.

That's possible. What about further usage? Will it has an access to the $HOME and config directories? I'm curious, because while I can make it work for specific commands it will panic later unless it has an access to these directories

btw, config directory can be specified with MANGAL_CONFIG_PATH environment variable

from mangal.

Also, if you're trying to get a shell completion it can be done without running completion command. It will always be the same, so you can just copy one from here

https://github.com/metafates/mangal/tree/dev/completions

from mangal.

That's possible. What about further usage? Will it has an access to the $HOME and config directories? I'm curious, because while I can make it work for specific commands it will panic later unless it has an access to these directories

For these kind of applications my go to solution is to raise a warning and give the users a safe default. So you know something is wrong but the functionality is still there. But it's more of an author design choice rather than a fixed rule.
Personally, I would give an init command to create the configuration files and handle errors with safe defaults and warnings.

btw, config directory can be specified with MANGAL_CONFIG_PATH environment variable

I didn't know about that, It does simplify the issue in my case as I can just set that environment variable to a temporary path.

It will always be the same, so you can just copy one from here

This is even easier. I thought the completions where auto generated by the library you use to handle commands.
I can just copy the files in the right folders as the last step of packaging. Thanks.

from mangal.

So you know something is wrong but the functionality is still there.

It's possible and mangal can function without any side directories, but that would make it harder for me to handle so I decided to create paths whenever they're mentioned so I can be sure that they exist. Maybe I'll change it in the future, but right now it's not really an issue, I believe

I thought the completions where auto generated by the library you use to handle commands.

It's true, actually. They are generated. I use this library and whoever made these completion scripts knew what they were doing lol. I created this completions folder for other reasons so it's not used by mangal directly

Tell me if you have any issues with MANGAL_CONFIG_PATH or completions when you're ready

from mangal.

About the completions, they are missing from the release 3.3.0

Added them to the main branch now, just in case

Glad that issue was resolved! I'll add Nix install option to the README as soon as it will be available, thank you!

from mangal.