Improve CLI interactions and caching URL

[elcritch]

Some more work on CLI and some related changes for speed.

• suppress redundant info like installed package foo on default outputs
• adds --info flag to print the extra info without a full verbose (MediumPriority)
• modifies nimble deps to print out only direct dependencies and versions
  • this seems more like what people expect when running nimble deps
• nimble deps --tree prints out the full dedendency tree
• info about url based deps are cached in a packages_nimblecached.json PkgList

I did some simple timing on one of my projects and get:

# Before cachine URL checks
figuro> nimble deps  2.03s user 0.55s system 26% cpu 9.877 total
# After caching URL checks
figuro> nimble deps  1.38s user 0.24s system 83% cpu 1.931 total

[elcritch]

I'd also like to add a nimble deps --update and maybe a nimble deps --install options. Ideally a nimble deps --update would be a great way to do network related work but upon explicit request. This is how Elixir's mix package manager works and it's great to use.

@Araq what would you think about adding that?

[Araq]

@Araq what would you think about adding that?

Fine with me but the naming could be better.

[elcritch]

I ended up removing the URL and pkginfo for URL requires from this since it's a bigger issue and was blocking the UX changes.

The nimble deps is also now colorized, which is nice:

[elcritch]

@Araq what would you think about adding that?

Fine with me but the naming could be better.

I left out the nimble deps --updated or nimble deps --install as well. They'd be nice, whatever others would prefer for names.

IMHO, in general the CLI options should be hierarchical to aid in discovery and memory. So "deps" options. When you add tab-completion it makes it easy for find things without referring to the docs constantly.

[elcritch]

Also added nimble list --nimbinaries

And colorized the package list and search:

[arnetheduck]

Indeed, deps is for viewing things and we want to keep "view my current state" and "change the state" apart - there should at some point exist a command for updating the deps but to have a reasonable UX, it depends on "local-first" mode - otherwise, if you have 2 nimble projects and run "update my deps" in one of them, the other project will also see its deps updated.

[elcritch]

Indeed, deps is for viewing things and we want to keep "view my current state" and "change the state" apart - there should at some point exist a command for updating the deps but to have a reasonable UX, it depends on "local-first" mode - otherwise, if you have 2 nimble projects and run "update my deps" in one of them, the other project will also see its deps updated.

That's a good point. I found Elixir's mix layout to make sense and to still keep view and modify distinct. They use a mix deps.<command> --opts format. In Nimble that'd be more like having nimble depsUpdate and a nimble depsInstall than having nimble deps --install. Mix is one of the least problematic PMs I've used, which is why I reference it. It's really good about doing things offline unless explicitly requested too.

it depends on "local-first" mode - otherwise, if you have 2 nimble projects and run "update my deps" in one of them, the other project will also see its deps updated

Hmmm, looks like we do have nimble update which seems equivalent to Mix's mix deps.update xyz. However whenever you install deps with Mix they're installed locally and creates a lock file. So it's a different model.