radian-software / straight.el

🍀 Next-generation, purely functional package manager for the Emacs hacker.
MIT License
2.71k stars 150 forks source link

Equivalent of describe-package #563

Open aspiers opened 4 years ago

aspiers commented 4 years ago

I was very glad to stumble across the stated goal of making straight.el as superior to package.el in all respects, not only some.

In this vein, as a long-time previous user of package.el who has just transitioned to straight.el today and is already enjoying the wealth of improvements, pretty much the only thing I've missed so far is an equivalent for describe-package. Hopefully this is something you might be willing to consider?

raxod502 commented 4 years ago

Yes, I agree, this would be a nice feature. Here is one way this feature could be implemented: When the user runs describe-package, we resolve the recipe and extract the Git URL for the package. We can add per-:host translators from :repo to a download URL for a file, and if the :host is supported then fetch the main package file and extract from there. It seems like it would have similar latency to what I see with package.el.

Alternatively, we could just clone (but not build) the package, on the assumption that there's a good chance you'd want to install it next anyway. We could also combine these two strategies and only clone when we can't fetch the package file directly.

As a third approach, we could script GNU ELPA and MELPA to just fetch package descriptions from their APIs in the same way as package.el does. This is probably the best strategy, and it could probably be used to provide a replacement for list-packages, which has also been requested.

aspiers commented 4 years ago

Thanks - these all sound like great approaches to me! And yes, some combination of them could also work nicely for optimal performance. I love that you have a package.el supremacy label ;-)

raxod502 commented 4 years ago

See also https://github.com/raxod502/straight.el/labels/ಠ_ಠ ...

progfolio commented 3 years ago

As a third approach, we could script GNU ELPA and MELPA to just fetch package descriptions from their APIs in the same way as package.el does. This is probably the best strategy, and it could probably be used to provide a replacement for list-packages, which has also been requested.

I feel like this is the best approach for now. I've been sketching out a UI and implementing a MELPA functionality for it. It shouldn't be too hard to have something with basic functionality together soon.

progfolio commented 3 years ago

Here's a very rough demo of what I have so far:

https://youtu.be/m2zpT9Fuj94

M-x straight-ui grabs MELPA's package metadata JSON and formats it into a table. Installed packages are highlighted. I've implemented a basic search which live updates as the minibuffer is updated (heavily inspired by elfeed). In the above demo, I search for "^helm$". Hitting return brings me to a package info buffer which displays the package's description, dependencies, dependents and any unpulled commits from the default branch. This is a magit buffer, so all the usual magit commands can be used to review the code/manage the repo.

The search engine also supports the following syntax at the moment:

Search terms separated by white space are checked against all table columns (regexp supported). Search terms prefixed by a ! are negated. Inserting a | indicates that you want to search against a particular column of the table. For example, the current table lists three columns: Package, Description, URL. Querying for ^ox- | html searches for packages with names that start with ox- and have descriptions containing html. Querying for ||raxod searches for raxod in the URL column:

blackout             Better mode lighter overriding                               https://github.com/raxod502/blackout
company-prescient    prescient.el + Company                                       https://github.com/raxod502/prescient.el
ctrlf                Emacs finally learns how to ctrl+F                           https://github.com/raxod502/ctrlf
diary-manager        Simple personal diary                                        https://github.com/raxod502/diary-manager
el-patch             Future-proof your Elisp                                      https://github.com/raxod502/el-patch
ivy-prescient        prescient.el + Ivy                                           https://github.com/raxod502/prescient.el
prescient            Better sorting and filtering                                 https://github.com/raxod502/prescient.el
selectrum            Easily select item from list                                 https://github.com/raxod502/selectrum
selectrum-prescient  Selectrum integration                                        https://github.com/raxod502/prescient.el

I've also implemented deferred marking (inspired by mu4e). From the UI buffer users can hit a single key to mark a package for installation and then batch execute the actions associated with those marks with another key press. Here we search for and batch install some dark themes:

https://www.youtube.com/watch?v=3wA3UnjCkh8

There are still many design questions to be answered. I'll continue experimenting with this and open a pull once it's minimally viable.

raxod502 commented 3 years ago

Wow, that looks awesome! Maybe would be simpler to just match search queries against all columns by default though, that might give something that works "well enough" while being simpler to use?

progfolio commented 3 years ago

Maybe would be simpler to just match search queries against all columns by default

Yes, this is how it works if no pipe characters are used. I've iterated on this more since those demos. I think one challenge will be properly caching results to make operations snappy enough. Still experimenting.

mathrick commented 1 year ago

Any news on your experiment? That would be incredibly useful UI to have.