Add upload support

[snoyberg]

Should be based on stackage-upload, and ultimately support GPG signature uploads to sig archive.

[gregwebs]

Can stackage-upload stay separate and stack upload would install stackage-upload and invoke it?

[snoyberg]

We could go that route. What's the motivation?

On Tue, Jun 9, 2015, 4:41 PM Greg Weber notifications@github.com wrote:

Can stackage-upload stay separate and stack upload would install
stackage-upload and invoke it?

—
Reply to this email directly or view it on GitHub
#225 (comment)
.

[gregwebs]

The main motivation is really to experiment with keeping up the modular architecture of stackage-*.

Minor points are that it can

• avoid bloat: The majority of packages built by stackage will be applications that are not uploaded to hackage
• make https upload more accessible to those not using stack. (once this functionality is merged, there will not be a desire to maintain stackage-upload).

The main downside of this approach is

• introducing an extra step of installing stackage-upload which could fail (but it should succeed if we peg dependencies)
• complicating feature discovery.

The latter point was a big issue for stackage-cli. However, if stack knows ahead of time that the upload functionality exists, then this seems solvable.

This modular architecture means that stackage-upload development can occur independently of stack This could actually create downside if stackage-upload wants to ask questions to stack, but I don't think it does.

[snoyberg]

It seems like there's a much simpler option available if we want: depend on the library exposed by stackage-upload. I like the fact that we have a batteries-included tool now, I'm hesitant to go in the opposite direction.

That said, I'm not even sure if I want to depend on an external library instead of just including the code here.

And I'm not concerned about bloat: the addition of the necessary 200-ish lines of code will not add any significant load to the binary size or source size.

[gregwebs]

Batteries included is definitely good. The goal with the modular architecture is to supply that same experience for most features, only adding a little delay sometimes to install a package needed for extra functionality.

But I can see how it is probably a lot easier to just add the module into stack in this case.

[snoyberg]

Added in cf87169