Straight.el: Equivalent of describe-package

Created on 24 Aug 2020  Â·  4Comments  Â·  Source: raxod502/straight.el

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?

compatibility feature interactive interface package.el package.el supremacy recipe repositories ux

Most helpful comment

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.

All 4 comments

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 ;-)

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

raxod502 picture raxod502  Â·  4Comments

enko picture enko  Â·  4Comments

mclearc picture mclearc  Â·  4Comments

aspiers picture aspiers  Â·  4Comments

dertuxmalwieder picture dertuxmalwieder  Â·  3Comments