Closed francisdb closed 5 years ago
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.
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?
@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.
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?
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.
@francisdb Although it's not yet merged to master, has this issue been resolved to your satisfaction?
I still need to look into testing but will create a new ticket is needed.
Creating this ticket as a discussion starting point to get a view on what the vision is regarding this:
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 https://github.com/haskell-fswatch/hfsnotify/issues/87
Running the
unison
binary from that folder does not work as the jvm runtime is not relative to the current path: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