Callable API for hex.outdated

[TylerWitt]

I am trying to go through dependabot's Elixir issues/PRs and clean it up, and one potential point of improvement is to create PRs for secondary dependencies, similar to the output of mix hex.outdated --all.

Dependabot already has a set of scripts in Elixir to manage mix, so my intent would be to call something like Hex.Deps.outdated(lock).

From what I see, all the functionality is currently in the mix tasks, which formats the table to IO. It would be helpful to have a callable function to get the list of dependencies without any IO/formatting concerns.

I don't mind doing the work for this, but I wanted to make sure it would be welcome before spending time on it.

[wojtekmach]

Thank you for opening up the issue. We don’t plan to have Hex public API per se and yeah Mix tasks are not appropriate for programmatic access. The public API people, including mix/hex and rebar and anyone, can use is in https://github.com/hexpm/hex_core. So the idea would be to reimplement hex.outdated using hex_core. I believe rebar3 does not have hex.outdated equivalent so I’m sure the team will be keen on having something they could build one on top of. I don’t think it will be straightforward as in hex core we have neither registry (as in ets table we can consult) nor functions like Version.match?(version, requirement) nor functions for working with lock files. So there would be quite a lot of heavy lifting to do first or it would be written in a way where the caller (being Mix/Hex, Rebar, etc) would supply the missing pieces like lock and semver functions right now and down the road we port to to hex core. If anyone of this sound interesting to you Tyler we would appreciate any help. @ericmj @supersimple @tsloughter Wdyt?

[TylerWitt]

I guess when I said API I more meant a callable function, and not a HTTP call.

Or is all programmatic access to hex meant to be through hex_core?

[wojtekmach]

The latter, yeah, some sort of outdated function.

[supersimple]

FWIW I consider hex_core to be he foundation of package management in BEAM ecosystems.
Anything we add there should probably only have the expectation of BEAM, and not make other assumptions about the environment.
The resolver and lock format for rebar and elixir are quite different, and the outdated function seems like it would need to imply some of the design of those two things to work as a user would expect.
Would it make sense to have an option on the Mix task (like --raw) that formats the output in a different way? perhaps as native terms?

[wojtekmach]

Good point maybe rebar would have wanted slightly different data out of such function which defeats the purpose.

In the meantime yeah I think we can add a flag. Raw is a good one. It could even instead be —-json as it’s easy enough to come up with it without a json library. We’d be setting a precedent for other Hex tasks to maybe follow in the future so need to be careful.

[TylerWitt]

I drafted this up a bit, with a slight refactor to facilitate the change #1061

Let me know if it is desired/helpful, or if y'all want to handle this change!