Skip to content

cabal got annoyingly chatty #10885

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.

Sign up for GitHub

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

Jump to bottom
Open
Bodigrim opened this issue Mar 30, 2025 · 6 comments · May be fixed by #10940
Open

cabal got annoyingly chatty #10885

Bodigrim opened this issue Mar 30, 2025 · 6 comments · May be fixed by #10940
Labels
re: project-file Concerning cabal.project files re: user experience User experience (UX) issue type: discussion
Milestone
Considered for 3.16

Comments

@Bodigrim
Copy link
Collaborator

Switch to any package with cabal.project and execute

$ cabal-3.14.1.1-p1 --semaphore build
...does some work...
$ cabal-3.14.1.1-p1 --semaphore build
Configuration is affected by the following files:
- cabal.project
Up to date
Created semaphore called cabal_semaphore_1 with 8 slots.

That's awful lot of lines to tell me that there is nothing to do. Older versions of cabal used to report briefly Up to date, which is much better. Could the default log level of Configuration is affected by... and Created semaphore... be adjusted please?

I mean, I definitely do not need to be reminded every single time that there is cabal.project in my folder. And it gets even worse if there is more than one *.project file. This is a valuable information to display at some verbosity level, but definitely not by default.

As for semaphores, I don't even see how one can act upon this message. Could it be relegated to -v3 only? Seeing it every time I run any Cabal command is mildly infuriating.
@ffaf1
Copy link
Collaborator

ffaf1 commented Mar 30, 2025

#10507

More output versus the misery of realising after ½h of debugging something is not working because of a cabal.project you were not yet aware of.
I take the former, I understand opinions may vary.

@geekosaur
Copy link
Collaborator

FWIW I'm in favor of the cabal.project message but think the jsem stuff can be moved to debugging information.

@ulysses4ever
Copy link
Collaborator

ulysses4ever commented Mar 30, 2025 •
edited
Loading

Related: #8519 (request to add the message about the project file in the standard verbosity).

I was thinking about it and currently am of the opinion that we might tweak the project file message to appear at normal verbosity only if the file comes from outside the current directory.

jsem stuff should be downgraded.

@ulysses4ever ulysses4ever added type: discussion re: user experience User experience (UX) issue re: project-file Concerning cabal.project files and removed type: bug needs triage labels Mar 30, 2025
@Bodigrim
Copy link
Collaborator Author

More output versus the misery of realising after ½h of debugging something is not working because of a cabal.project you were not yet aware of.

That's what --verbose is for, eh? If one doesn't understand what's going on, enable it to gain a deeper insight. But I don't need to be reminded every time about a bog standard cabal.project.

Things get progressively worse if there is more than one file. In practice one receives something like

Configuration is affected by the following files:
- cabal.project
- cabal.project.freeze
- cabal.project.local

It would be less irritating if at least displayed on a single line, e. g., Configured using cabal.project, cabal.project.freeze, cabal.project.local.

I was thinking about it and currently am of the opinion that we might tweak the project file message to appear at normal verbosity only if the file comes from outside the current directory.

That would work for me, thanks.

@ulysses4ever
Copy link
Collaborator

if at least displayed on a single line

That I also considered and I think it's a good idea too.

@TeofilC
Copy link
Collaborator

TeofilC commented Apr 2, 2025

See also: https://clig.dev/#output

Display output on success, but keep it brief. Traditionally, when nothing is wrong, UNIX commands display no output to the user. This makes sense when they’re being used in scripts, but can make commands appear to be hanging or broken when used by humans. For example, cp will not print anything, even if it takes a long time.

It’s rare that printing nothing at all is the best default behavior, but it’s usually best to err on the side of less.

Of course this is just one set of CLI guidelines

@RyanGlScott RyanGlScott mentioned this issue Apr 17, 2025
Merged
ulysses4ever added a commit that referenced this issue Apr 22, 2025
@ulysses4ever
print out the "Created semaphore" message only in verbose mode (#10885)
217767d
@ulysses4ever ulysses4ever mentioned this issue Apr 22, 2025
Merged
6 tasks
ulysses4ever added a commit that referenced this issue Apr 22, 2025
@ulysses4ever
print out the "Created semaphore" message only in verbose mode (#10885)
b4b96de
@ulysses4ever ulysses4ever added this to the Considered for 3.16 milestone Apr 24, 2025
mergify bot added a commit that referenced this issue Apr 25, 2025
@ulysses4ever @mergify
Print out the "Created semaphore" message only in verbose mode (#10936)
df9a83a 
* print out the "Created semaphore" message only in verbose mode (#10885)

* fixup! Update pr-10936.md

---------

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
@ulysses4ever ulysses4ever linked a pull request Apr 26, 2025 that will close this issue
Draft
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
re: project-file Concerning cabal.project files re: user experience User experience (UX) issue type: discussion
Projects
None yet
Milestone
Considered for 3.16
Development

Successfully merging a pull request may close this issue.

make cabal less chatty w.r.t. project files in use haskell/cabal
5 participants
@TeofilC @geekosaur @Bodigrim @ulysses4ever @ffaf1