Support git repos / http folders in packages stanza

[mboes]

Currently, if a package depends on a patched up upstream, the recommendation found in the FAQ is to check out the package as a git submodule, or unpack the source code for that package in some local directory.

However, often it's not so much that a user wants to depend on a patched up package, as the fact that the user is depending on an unreleased version of upstream. In this case it would be nice to be able to directly point to a remote repository, or to a commit hash in some remote repository, directly in the stack.yml file without needing to checkout the remote code just for the purpose of building against it.

[UnkindPartition]

Wow, that'd be pretty awesome!

[chrisdone]

+1 I've had the use-case once or twice.

[snoyberg]

If we make some simplifying assumptions, this should be trivial. In particular: assume that the URL or Git commit represents something immutable. Then we unpack/clone into a directory inside .stack-work and just treat it as an unwanted local package. Does this sound like a reasonable simplification?

[chrisdone]

Where "unwanted" means "not a wanted target" in the Make-like stack build step of demanding stack build TARGET1 TARGET2 or when stack build the targets are the implicitly wanted packages listed in the stack.yaml file.

[gregwebs]

cabal-meta does much of this and works with darcs also

[snoyberg]

I already have an issue open about merging in mega-sdist functionality. Are you opposed to absorbing a few other of the cabal-wrapping tools we've created over the years?

[gregwebs]

This is another tool that could possibly stay as a separate executable, except that the tool could benefit from stack's knowledge of stack.yaml. The downloading tool could look for a stack.yaml in the repo (like how cabal-meta looks for a sources.txt) to find where the package is in the repo instead of requiring the user to supply that information (default of course would be ./).