best practice for depending on a branch of a library

[ceedubs]

Is your feature request related to a problem? Please describe.

Sometimes it is useful to be able to upgrade to an in-development version of a library before that branch of the library has an official release. Examples:

• A fix/feature has been merged to /main but the library maintainers haven't cut a release with it yet.
• You want to test the downstream affects of a library change before committing it to a release.
• You want downstream library support to be established before a release is advertised.
  • For example the Unison Cloud backend depends on types and tests in the Cloud client library, so we need to update the cloud client for new features. But we don't want to officially release features in the Cloud client library until the backend supports them.

Describe the solution you'd like

• A documented best practice for depending on a version of a library that only exists in a branch (not a release). Preferably that will work even if the branch is local and hasn't been pushed to Share.
• Possibly/ideally something that doesn't clutter the dependent library with the entire history of the dependency library. This point can potentially be ignored if there is evidence that it isn't an issue. But cloning projects can currently take dozens of minutes, and I don't want that time to go up if this flow is used.
• Something that plays nicely with the upgrade command (and its friends like upgrade.commit).

Additional context

I've asked about this a few times like here, here, and during a Nimbus pairing session, but I've never really gotten an answer.

[aryairani]

Something that seems to work for the moment uses merge.old.squash (which was admittedly on its way out):

@me/app/main> lib.install @x/foo
.. installing as x_foo_releases_15_0_2 ..

@me/app/branch> <hack hack hack>

@me/app/branch> clone @x/foo/main @x/foo/jun_17
(possibly substitute your own steps for the previous, but i included it for clarity)

@x/foo/jun_17> switch @me/app/branch

@me/app/branch> merge.old.squash @x/foo/jun_17 lib.x_foo_jun_17
... some antithetical output ...

@me/app/branch> upgrade x_foo_releases_15_0_2 x_foo_jun_17

A similar option today is to use

fork @x/foo/snapshot: lib.x_foo_snapshot

instead of merge.old.squash, but this does incur the entire dependency library history.

---

Obviously, this isn't great. With "real" dependencies, we had always expected to want to depend on a development branch; but that doesn't help us today.

Another issue is that the namespaces for local and remote branches unfortunately overlap (i.e. you can't tell from @x/foo whether you're talking about a remote project or a local one).

We could do this as a lib.install-local maybe?

Let me know what you think.

[ceedubs]

Thanks @aryairani. For now merge.old.squash is doing what I need.

The ambiguity between local and remote paths does seem problematic. I wonder what other situations it could come up. But setting that aside for a moment (and thus ignoring the potential need for a lib.install-local), does lib.install squash if you provide it a branch instead of a release? It seems like it probably should, right?