Open aspiers opened 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.
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 ;-)
See also https://github.com/raxod502/straight.el/labels/ಠ_ಠ ...
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.
Here's a very rough demo of what I have so far:
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.
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?
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.
Any news on your experiment? That would be incredibly useful UI to have.
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 tostraight.el
today and is already enjoying the wealth of improvements, pretty much the only thing I've missed so far is an equivalent fordescribe-package
. Hopefully this is something you might be willing to consider?