scala-cli
scala-cli copied to clipboard
VirtusLab
Add a way to search for dependencies
Is your feature request related to a problem? Please describe.
Right now, to add a dependency one needs to precisely know how to get it and pass it with a using directive or an option.
For example, to depend on ujson one needs to know it is a part of upickle.
Then com.lihaoyi::upickle:1.6.0 is the answer, which wasn't necessarily obvious.
Of course, a quick web search would provide this information, but we could implement some way of dependency search or listing from the command line with Scala CLI.
Describe the solution you'd like A way to find the dependency I want with a text query from the command line, preferably with an option to include it in my current workspace.
Describe alternatives you've considered A web search is the workaround, but something closer to the terminal and/or the IDE would be better.
Additional context
- https://github.com/VirtusLab/scala-cli/pull/871 - a past attempt at solving this
- https://contributors.scala-lang.org/t/why-doesnt-scala-have-library-listing/5696 - a potentially relevant discussion from the Scala community
Note that there's prior art in the form of a VS code extension that talks to Scaladex: https://github.com/Baccata/vscode-scaladex-search
Just to bump it - there's a CLI based on Scaladex APIs: https://github.com/neandertech/dexsearch
A natural language search over descriptions AND a search over just library names would be ace.
I think we should not add it to Scala CLI. It's perfectly fine to sit as a separate CLI command and it's already handled in Metals, where it's much more useful than manually searching got everything.
and it's already handled in Metals, where it's much more useful than manually searching got everything
Where is it handled by metals? Metals doesn't have a search function afaik.
It's perfectly fine to sit as a separate CLI command
Yet another (unofficial) CLI command is not a good experience for beginners, especially given both NPM and Cargo have search functionality.
I'm all for trimming the scope, but scala-cli is a swiss army knife already (as it should be!), and there's so far no good justification for not including this, given how low lift it will be.
And the interaction between different CLI tools has proven to be a nightmare in any ecosystem - flags, output formats (cargo outputs stuff you can paste into Cargo.toml, npm - doesn't), etc.
IMO there is no good justification to ever say "separate CLI will work just fine" given the
- past history in any ecosystem, and
- the desire to have a powerful scala command
Where is it handled by metals? Metals doesn't have a search function afaik.
Not search, but complete, so not ideally the same thing, but we can add also a scaladex search.
Yet another (unofficial) CLI command is not a good experience for beginners, especially given both NPM and Cargo have search functionality.
Sure, but on the other hand how is search useful for beginners? How will they know what to search for or that a method like this even exist? We should incorporate this into editors/IDEs, which is most likely to be used by beginners. Or use Scaladex itself, which will be comfortable enough. Having search in the CLI is more of an advanced usage.
I am not totally against adding this, but having a thin wrapper over API invocations seems like could be problematic to maintain:
- API might be often down and we can't really run automatic tests (or shouldn't) to see if things broke
- some environments might be hard to make it work in so we will get a load of new problems to deal with
Why having it as a separate CLI is a problem? We don't plan to incorporate this feature into any standard workflows in ScalaCLI anyway, this would be a totally separate thing with no interaction at all with other parts of the code.
We revisit this at some point, but we don't plan to work on it currently, since we have a bunch of existing flows that require a lot of attention. If anyone wants to work on this as an outside contribution that's totally fine
Och and what happens if there is no one to maintain scaladex or the servers? We would need to implement our own solution based on maven central, which would be most stable.