Awesome bar functionality

[choldgraf]

A few people have noted their frustration with the main "repo path" text box (e.g. #339). We've discussed at various points having some kind of "awesome bar" functionality. The idea is that users would only need to paste a single URL and it'd "figure out" how to populate the various URL parameters automatically.

I think this could be a nice way to support more build packs without adding a lot of extra UI cruft for each one. Is this something that'd need to happen on the javascript side?

---

We have two main proposals right now:

1. Use a single function that takes a git url and breaks it up into relevant pieces (e.g. org name, repo name, ref, etc), then depending on one of those fields (e.g., "url = "github.com") trigger different build packs. A library to do something like this exists here: https://github.com/IonicaBizau/git-url-parse
2. Build a detect method for each build pack that parses the URL and extracts relevant info. Then we can loop through each build pack to see if detect returns True and start building from there. I think this could be better at dealing with heterogeneous url structures/metadata. (suggested in Add an API endpoint that resolves arbitrary URLs into specs #322)

In the name of not re-inventing wheels and using community projects where possible, what if we went with a hybrid between the two. Used a detect method for all build packs, and for the subset that we know is parseable by git-url-parse we just use that to break up the URL rather than writing our own code for each one.

Open questions:

1. Choose some combination of the options above
2. Choose an endpoint (e.g., /v2/url/<arbitrary-url>?<arbitrary-extra-params>)

[minrk]

Sounds great and should be relatively easy for GitHub (can even get filePath or urlPath from blob/tree URLs). Might be a little trickier for something like raw git, but we can do it.

[choldgraf]

And just to clarify, this would need to be on the JS side right? E.g., we couldn't make some patches to https://github.com/FriendCode/giturlparse.py and use that?

[willingc]

Other than not knowing what "awesome bar" is, I think that the intent of this enhancement is a good one 👍

[minrk]

@choldgraf not technically, as we could make an extra HTTP request with the raw URL that does the parsing server-side. But I think doing it client-side probably makes the most sense.

[choldgraf]

note that I've got a PR here to add a bit more git URL parsing to the giturlparse tool: IonicaBizau/git-url-parse#42

which we could use after #372 gets merged

[choldgraf]

in reference to @yuvipanda 's comment here: #372 (comment) (since it was awesomebar-specific and it'll be easier to keep track of discussion here)

I don't see how your note of an API endpoint and the git-url-parse package are in conflict. I agree w/ you about having an API endpoint to parse a url, tell you whether it's github/gitlab/gist/etc, and return that information as JSON. I was suggesting that we use the git-url-parse for the initial "split a random git URL into structured data so we know what is the repo / username / etc", then we would repackage that as JSON however we like, rather than writing our own git repo parsing code. But maybe I am missing something?

[choldgraf]

ahhh I see, I just re-read your comment. You're suggesting to use a detect method, one per build pack, rather than having a single function to handle them. I updated the top-level comment to reflect those two proposals.

[lheagy]

👍 I am also not totally clear on what an "awesome" bar is, but the functionality improvements sound great! I have gotten tripped up expecting that I could copy-paste a url to specific notebook in a repo and expected that binder would figure out that the branch and notebook-endpoint from that url.

[yuvipanda]

I think awesome bar refers to https://support.mozilla.org/en-US/kb/awesome-bar-search-firefox-bookmarks-history-tabs, which almost all browsers have now so we take for granted...

[nuest]

Should this be closed in favour of #844 ?

[choldgraf]

I'm happy to do so if that issue is gonna get more action than this one moving forward