-
Notifications
You must be signed in to change notification settings - Fork 358
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
Add a verbose-on option. #5682
Add a verbose-on option. #5682
Conversation
4db9e45
to
c25a4e1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for this first PR!
I've put some comments, but the general idea on how you add it is good!
Please tell me if you need more precision!
src/client/opamArg.ml
Outdated
let verbose_on = | ||
mk_opt ~cli (cli_from cli2_2) ~section ["verbose-on"] "PACKAGES" | ||
"Be more verbose on specific packages." | ||
Arg.(some (list package)) None ~vopt:(Some []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here you have verbose_on
and a name & version opt list, but only names are used. It'll be better to take only name list. You can use OpamArg.name_list
Arg.(some (list package)) None ~vopt:(Some []) | |
Arg.(some name_list) None ~vopt:(Some []) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be better to allow full package name + version as it is currently. This way the feature would be much simpler to use, especially in CI systems where this would be most useful
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we have name.version, it can be used only if user knows in advance which version of the package will be installed, which is not always the case.
In usual CI, you may want to have install log of the package you are testing (usually yours), and its inner version can change.
What do you have in mind about disadvantages of only name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok fair, let's do name only for now, we can always add name.version later if we want or if requested
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could evolve into name.optional-version, like that we have all advantages :)
I've added a test ( I've also rebased your PR, we prefer rebasing on master than merging master for PRs, it eases history/commits lookup. |
Thanks for your review, I did it a bit late... but I think there's nothing more to do about what you said, I'll however say I don't exactly know how to test env variables, and I'm not sure if what I did works (at least it compiles!) |
No worry! We'll try to review the changes in the next weeks. We are also focused on the 2.2 release on our side :) |
88c67ec
to
7dc4421
Compare
It's been some time, do you have any update on this? |
Sorry for the delay, we are still diving into the release of 2.2 (that is in its beta2 since 2 days). I've put some comments, with these modification and an update of master_changes (points to add in Client, Reftests, and API), the PR should be nearly complete. |
Thanks for your reviews, I commited the changes. |
Co-authored-by: Raja Boujbel <[email protected]>
1fc9017
to
e6c6afa
Compare
Now opam 2.2 is out, we can take a look again to other PRs @desumn. I've updated the PR: update some code, squashed intermediate commits, update changelog, etc. |
?verbose_on: | ||
(b.verbose_on >>= function | ||
| [] -> None | ||
| vo -> Some (OpamPackage.Name.Set.of_list vo)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current behaviour I've implemented: if the flag list is empty, it is considered as nothing was given. Same for environment variable.
### : unknown package | ||
### opam reinstall qux --verbose-on unknown-pkg | unordered |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On unknown package, nothing is printed, should we?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the current behaviour is fine
e6c6afa
to
0d2588d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've remove a couple of local opens (which in my opinion we should avoid for readability and maintainability purpose). lgtm now
Implementation of #5331
Add a
verbose-on=PACKAGES
parameters to build options. For the time being, it's equivalent to a simple-v
for a list of package.I'm not sure how I'd be able to simulate a modification of the opam file of a specific package to change add the verbose flag, so it's not exactly what #5331 asked for, however if there's a way I'd be glad to implement it!