Allow running/compiling/testing unison from anywhere

[francisdb]

Creating this ticket as a discussion starting point to get a view on what the vision is regarding this:

• What binaries will be available?
• Do we expect to need some kind of build tool, do we plan to plug in to an existing one?
• How would you develop/test/distribute a library?

---

Current state of things below (this is not what this ticket is about)

I create a git repo to store some unison files I am working on and want to compile/test it.

Symlinking the folder into unison-src does not work
haskell-fswatch/hfsnotify#87

Running the unison binary from that folder does not work as the jvm runtime is not relative to the current path:

../unison.francisdb/parser-typechecker/.stack-work/dist/x86_64-osx/Cabal-2.2.0.1/build/Unison/unison
unison: sbt: createProcess: runInteractiveProcess: chdir: does not exist (No such file or directory)

The new haskell runtime can start from a unison file but is not yet usable

Will make the scratchFilePath customizable with an argument which should help me forward

[aryairani]

There will be a single unison executable that can be run from any directory. This is the compiler and build tool and app launcher. There can also be a flag to specify the watch directory, or else watch the current directory.

The .unison folder can be versioned on Github along with any scratch .u files, although any definitions that typecheck can just be added to the .unison codebase. We plan to have a way to browse the codebase in text form at github.com.

[francisdb]

How would one then create / share a library for use by other projects?
Uploading to a central unison cloud repo?
And how would you write/store tests?

[aryairani]

@francisdb Initially, you could share a library with others just by publishing libraries as branches in your .unison directory in your github repo, someone could download from github and merge into their local codebase. This will naturally be easier once you're not limited to running unison within the Unison tool's build directory. I set up an example repo here, in case you're interested in playing around with it.

In not too long, I think we'll have a syntax in the CLI (or even in a .u file) for referencing a library's branch on github. This would automatically add the branch to your codebase, and you could merge that branch into yours to gain the library functions it published. Eventually this process will be more polished, including probably some more fine-grained options.

Uploading to a central unison repo might become a thing.

The story for tests is a work-in-progress, but you would write them like any other unison function.

[francisdb]

Somehow storing .unison in a git repo is like storing one version control system into an other one

How would you work with that example repo in case you want to add it to your own project?

[aryairani]

I suppose it is. Many IDEs maintain a local file history too! Then you have 3 revision control systems. 😄 You might consider old versions of functions that you keep around in your Scala or Haskell source repo (just in case you might want to use or reference them eventually) to be a 4th revision control system. (I do.)

In any case, to work with that remote .unison codebase, it needs to be recursively merged with yours. We have taken some pains to ensure that .unison directories will merge cleanly. You can use the git tool to achieve this, simply by merging that remote repo with something like:

git remote add arya-libs https://github.com/aryairani/unison-libs.git
git fetch arya-libs
git checkout -m arya-libs/either -- .unison

then within the unison tool:

master> merge either

  Merged. Here's what's `todo` after the merge:


  ┌
  │  ✅
  │  
  │  No conflicts or edits in progress.
  └

master> ls Either

  type Either
  Either.leftToOptional  : Either a b -> Optional a
  Either.>>=             : Either a b -> (b -> Either a c) -> Either a c
  Either.fromRight       : b -> Either a b -> b
  Either.either          : (a -> c) -> (b -> c) -> Either a b -> c
  Either.fromLeft        : a -> Either a b -> a
  Either.isRight         : Either a b -> Boolean
  Either.rightToOptional : Either a b -> Optional b
  Either.isLeft          : Either a b -> Boolean
  Either.Left            : a -> Either a b
  Either.Right           : b -> Either a b

master> 

  ┌
  │  1 | >Left 3
  │        ⧩
  │        Either.Left 3
  └

master>

You're supposed to be able to do the git checkout -m even while unison is running, if not for #347. For now, try restarting the tool if it seems to be out of sync after the merge.

Eventually the Unison tool will provide commands to do all of this for you, or to directly interact with the remote repo from the terminal or from the import statements in your .u file.

[aryairani]

@francisdb Although it's not yet merged to master, has this issue been resolved to your satisfaction?

[francisdb]

I still need to look into testing but will create a new ticket is needed.