Add download button near perspective and modal

[hojberg]

Overview

Add a new download button near the perspective details that when clicked
shows a new download modal with pull instructions and a command copy
field. This button only shows up on Unison Share.

This fixes #145

Implementation notes

The copy field uses a webcomponent to reach out from Elm into JS and
access the clipboard.

Interesting/controversial decisions

The download command being generated also uncovered a problem with the
way FQNs were being deserialized, such that they'd always include a .
prefix. This lead to some strange URLs and didn't buy us anything and was removed.

Extracted the FQN dot fix into #210

[pchiusano]

I have some concerns about this one, even though I like the idea a lot!

Share currently has a miscellaneous collection of releases and copies of trunk from different libraries, including base. If people download stuff from Share, they won't have an easy way to know what version they're using and there's a good chance it's one that isn't actively being supported by the maintainers (like it has an old version of a data type that existed in trunk temporarily but was refactored).

If people are going to download an unreleased thing meant as more of a preview, that should be indicated somehow.

Also, we're missing some indication of where the library's canonical location is, if you want to contribute changes back.

I do want library installation to be this easy and discoverable but I'm concerned that this button makes it easy to accidentally do the wrong thing and create a mess.

I'm not sure what to do about this:

• First idea is that Share could be rebuilt regularly from a text file or transcript, and it can squash all the namespaces (later, it could truncate history instead). This way, there's a file which makes it clear what versions are being displayed and gives their canonical locations. The publishing process is simpler as well, especially for libraries like distributed which are just in preview mode.
  • This could be done in the short term.
  • This would also provide an easy way to refresh Share with the latest releases, which should definitely be done.
• Ideally, this version info and canonical location info could be surfaced in the modal. Like it can tell you which command to use if you want to fetch the full library for contributing changes back, and which to use if you just want to install the library.
• Another idea - if the namespaces themselves could indicate where they were pulled from, then that could be surfaced automatically. Requires a bunch of backend changes. cc @aryairani
• Any package on Share should have a Readme doc indicating its version, status, and canonical location for contributing changes back. If this is missing, the download instructions could indicate something to this effect.

[hojberg]

@pchiusano yeah I think this is a very valid concern (I brought this up in #base-dev a few days ago). Especially with base since this is the most used library right now and the version thats on Share is not the latest release.

I think the right solution here has to do with projects, but in lieu of that, the readme option seems like a high impact, low effort way to deal with this without making things difficult for us later when we find out how to deal with projects.

Alternative, (or perhaps simultaneously) we can try brainstorm on the project dependency features with download from Share particularly in mind for a v1 of projects.

[pchiusano]

The Readmes are a good idea, but there's the problem of what to do about all the stuff that's already on Share that has no Readme.

I think rebuilding Share from a transcript would go a long way and is doable in short order. I think we could also put version hints in the namespaces. Like put random snapshots of trunk in a preview/ subnamespace:

base/
  M2h/
preview/
  distributed/
  http/
  parsing/

And maybe the modal gives some warning if you're downloading something from the preview subnamespace.

[hojberg]

I'm worried about cluttering the namespaces with structure that should really be meta data resulting in strange download commands, but perhaps there's a decent middle ground there.

Let's connect on this and the transcript idea, it's not clear to me how we get meta data around the canonical location into Share.

[hojberg]

I'm going to extract the non download modal parts of this into a separate PR.

Edits:

• fixed FQN dot issue here: Don't include . prefix in FQN decode #210

[hojberg]

Closing in favor of #278