Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ask about (or at least signpost!) init --interactive #7100

Closed
tom-audm opened this issue Oct 2, 2020 · 8 comments
Closed

Ask about (or at least signpost!) init --interactive #7100

tom-audm opened this issue Oct 2, 2020 · 8 comments

Comments

@tom-audm
Copy link

tom-audm commented Oct 2, 2020

I'm finding cabal init defaulting to non interactive insanely frustrating, particularly because there's no indication for users of how to get the interactive behavior. No note when the init happens, no documentation in cabal --help.

If you want to, say, init a library, and don't have all the required fields memorized, you probably want to use "--interactive". This is a basic need. Making basic tinkering with libraries more difficult just creates a subclass of users who are unable to contribute.

What I think is best

$ cabal init
Create automatically using sensible defaults? (y/n): y
Initializing using sensible defaults. You can make "cabal init" default to this by [...]
[...]

Bare minimum

$ cabal init
Defaulting to non-interactive init. To use interactive instead, use "cabal init --interactive". You can set the default in [...]
@gbaz
Copy link
Collaborator

gbaz commented Oct 2, 2020

👍 This should be an easy PR to do the "bare minimum" -- care to go for it?

@hvr
Copy link
Member

hvr commented Oct 3, 2020

I'd argue that cabal init invoked without any flags in non-interactive mode is very unlikely to be what you want. In fact, if you accidentally invoke it in the wrong folder you get no warning and you end up with a couple of files written in your current folder.

Consequently, since using cabal init non-interactively almost always involves supplying CLI flags to be useful, it doesn't seem too onerous to me to have cabal init default to interactive IMO, which as you seem to imply would be your preferred outcome.

For completeness, as you know there was quite a bit of controverisal discussion in #5902 which motivated for better or worse switching cabal init to non-interactive mode.

@emilypi
Copy link
Member

emilypi commented Oct 3, 2020

I would be more in favor of switching to back to interactive by default, and providing a note that tells you how to switch off the flag. Having non-interactive be the default is incredibly onerous to me because of the two contrasting workflows. Suppose each flag leaves a note about turning on/off their contrasting flag:

  1. if --interactive is the default and i mess up and forgot to switch on the non-interactive flag, nothing happens, and I can Ctrl-C out pretty easily to cancel the operation. Additionally, if there is a note about how to switch off --interactive, i can view that before proceeding, and quit out easily, using the flag as desired.

  2. If non-interactive is the default, and i forget to switch to --interactive, it dumps crap immediately into whatever directory i'm in, giving me a note. Now i have to clean up what Cabal just dumped into that directory, before proceeding with using the --interactive flag. If this is my first time using Cabal, even with a warning, init will just dump crap in a directory without rhyme or reason, and that will be my first experience building a project with the tool. I will not know what it dumped, and nothing is explained to me. It doesn't even use the "annotate each field in the .cabal option with helpful comments" option by default! That to me is more of a UX problem than having people not know what value to put for a particular interactive field. Oh, and the output isn't even accurate:

    λ П(a: A) tmp → λ git master* → cabal --non-interactive
    Guessing dependencies...
    
    Generating LICENSE...
    Generating Setup.hs...
    Generating CHANGELOG.md...
    Generating exe/Main.hs...
    Generating tmp.cabal...
    

    generates:

    λ П(a: A) tmp → λ git master* → ls
    CHANGELOG.md LICENSE      Setup.hs     exe          src          tmp.cabal
    

    Given what the script says it's doing. src/ is a suprising directory. We could probably add that
    last bit as color for the issue I raised for that prior to this Choosing library in init dialogue still creates exe dir #6772.

And for the record, yes i did switch the --interactive flag on in my global config. However it's undocumented in the readthedocs, and is only featured on that particular issue that @hvr posted. I am more in favor of producing high-level, easy to digest documentation showing what each option in the interactive script does, and how to automate them in the global config than doing it for users and hanging them out to dry without good docs. /rant

To get back on topic, I think as far as action items go, yes, leaving a note is better than the status quo. But i would like to reopen the discussion about whether that work is necessary in the first place.

@gbaz
Copy link
Collaborator

gbaz commented Aug 28, 2021

I believe that init is now back to interactive by default, so closing on that basis?

@gbaz gbaz closed this as completed Aug 28, 2021
@Mikolaj
Copy link
Member

Mikolaj commented Aug 28, 2021

Yes, it is, in 3.6.

@gbaz
Copy link
Collaborator

gbaz commented Sep 18, 2021

Wait, this doesn't appear to be the case in 3.6 after all? I'm very confused.

@Mikolaj
Copy link
Member

Mikolaj commented Sep 18, 2021

@gbaz: you are right, I mixed up master with 3.6. It's not interactive in 3.6, but will be in 3.8. I hope I got it right this time?

Edit: which, if it's right, probably means we should close this. But better to compile and check master.

@gbaz
Copy link
Collaborator

gbaz commented Sep 18, 2021

ok, just checked master and indeed its changed on master. closing again :-)

@gbaz gbaz closed this as completed Sep 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants