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

opam search --depends-on/required-by can be quite misleading #3943

Closed
dbuenzli opened this issue Jul 27, 2019 · 5 comments
Closed

opam search --depends-on/required-by can be quite misleading #3943

dbuenzli opened this issue Jul 27, 2019 · 5 comments

Comments

@dbuenzli
Copy link
Contributor

dbuenzli commented Jul 27, 2019

opam search makes it easy to make wrong inferences. For example:

> opam search --depends-on bos | grep odoc  
odoc           1.4.1       OCaml documentation generator

odoc 1.4.1 no longer depends on bos, but earlier versions did.

Also since since I'm moving to at least 4.03 and/or 4.05 I'm trying to get rid of my result package dependencies. But I'm often surprised by the unioning behaviour of --required-by:

> opam search --required-by topkg | grep result 
result     1.4         Compatibility Result module
> opam search --required-by topkg.1.0.1 | grep result 
> 

It would be nice to have an option, say --latest that

  1. on --depends-on PKG only show packages whose latest version depends on any version of PKG.
  2. on --required-by PKG only show packages that are required by the
    the latest version of PKG (I know PKG.X.X.X does that but then I have to remember the latest version number of my packages and I do not, but opam does).
@dbuenzli dbuenzli changed the title opam search --depends-on/require-by can quite misleading opam search --depends-on/require-by can be quite misleading Jul 27, 2019
@dbuenzli dbuenzli changed the title opam search --depends-on/require-by can be quite misleading opam search --depends-on/required-by can be quite misleading Jul 27, 2019
@ghost
Copy link

ghost commented Jun 1, 2020

I'd like something like this as well. Most of the t ime, I'm only interested in the latest version of packages.

@avsm
Copy link
Member

avsm commented Jun 1, 2020

To clarify this, could you describe the usecases you're putting this search to?

We need to define "latest version" slightly more precisely, since it also includes package versions that are eliminated by the ocaml compiler version, architecture and os constraints. So in this case, do you want to eliminate reverse dependencies that are not at their latest versions irrespective of installability, or to find the latest set of fresh reverse dependencies that are installable in the current switch.

For a CI revdeps usecase, filtering through the results of the existing command and then testing local installability of the resulting package set is what works. It would be useful to understand what other uses this feature might need.

@dbuenzli
Copy link
Contributor Author

dbuenzli commented Jun 1, 2020

So in this case, do you want to eliminate reverse dependencies that are not at their latest versions irrespective of installability, or to find the latest set of fresh reverse dependencies that are installable in the current switch.

Both. The --installable flag already exists so:

--latest               # as per latest version described in the repo
--latest --installable # as per latest version installable in the switch

@ghost
Copy link

ghost commented Jun 1, 2020

Myself, I'm interested in properties that hold at the tip of the project. I'm assuming that the highest version is the one that is the closest to the tip of the project.

For instance, this morning I was asking myself how many projects are using ocaml-migrate-parsetree directly and are not using ppxlib. For that, I was hoping to take the output of opam list --depends-on ocaml-migrate-parsetree -s and remove the ones that depend on ppxlib. But that yielded too many things such as async. In the end, I grepped through the dune-universe and found my answer, so for me it's only a weak request at this point.

@dbuenzli
Copy link
Contributor Author

dbuenzli commented Oct 8, 2024

I think this was closed by #5375

@dbuenzli dbuenzli closed this as completed Oct 8, 2024
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

3 participants