allow `usePantry().project()` to use `display-name:`

[jhheider]

This is going to be controversial. However, since everything under project() uses yaml() (except provider() which should get some love), we can do the lookup in one place.

• it involves walking the pantries, which will get awful over time
• it slows down failures to find packages
• but it should allow people to use display-names with tea: tea +Auto-GPT sh
• ~there's a little duplication in yaml() that could be factored out~ handled

I don't know who wants this or why, but it seems like it could be a good idea.

ETA: one of the benefits here is that is means less of a research task to move from the GUI to the command-line (for named packages). The disconnect still exists for packages who have their URIs trimmed, but one thing at a time.

ETA2: obviously, just like searching the provides or anything else that walks the pantries, this can be sped up by making useSync write out some metadata rollup to sqlite.

ETA3: we don't currently have any providers with display-names. But it shouldn't be hard. You'd just either duplicate the walk check, or make project() itself async so it can do the scan when its called. either seemed out of scope at this time.

[jhheider]

fun. works on mac, but not linux or dnt. let's see why.

ooh, and dnt runs on mac. fun!

[jhheider]

oh. facepalm. not available on linux.

[jhheider]

i love when it goes green.

[mxcl]

yes. maybe. however we need to handle duplicates for this case.

Also feel there is an argument that project should remain unique-names only and another function should be added that searches display-names (and provides!).

So maybe we just move this to a new function? Looking for thoughts.

[jhheider]

we would not be very nice if we had duplicate display names. the impulse came from the idea of improving interop between the gui and cli, such that you can quickly copy (or type) the name as shown in the gui.

i think provides are probably well-enough handled by both magic and tea foo. this can definitely go into a new function. if we provide a findByCanonicalName, findByDisplayName and findByProvides (which), then we can mix and match them in the the usage interfaces as appropriate. including, if we're clever, find(string, [nameType]).

[mxcl]

we would not be very nice if we had duplicate display names

yeah I was thinking of clashes with display-name and provides, but also in theory we could end up with a normal FQD style name that matches a display-name eg. if the display name was nodejs.org for some reason

[jhheider]

preventing clashes should easily be done in audit.ts as/if/when we have/change rules regarding things like this.

[mxcl]

Should be a separate function find that takes options specifying scopes defaulting to display-name, provides and project name.

[jhheider]

Your wish is my whatever that is.

[jhheider]

Of course. I was trying to seamlessly extend project() without introducing an additional await, but separating them is nbd.

[mxcl]

Closed in favor of #37