Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add upload support #225

Closed
snoyberg opened this issue Jun 9, 2015 · 6 comments
Closed

Add upload support #225

snoyberg opened this issue Jun 9, 2015 · 6 comments
Assignees
Milestone

Comments

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

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

@snoyberg snoyberg added this to the First stable release (0.1.0.0?) milestone Jun 9, 2015
@gregwebs
Copy link
Contributor

@gregwebs gregwebs commented Jun 9, 2015

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

@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Jun 9, 2015

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
Copy link
Contributor

@gregwebs gregwebs commented Jun 9, 2015

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
Copy link
Contributor Author

@snoyberg snoyberg commented Jun 9, 2015

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
Copy link
Contributor

@gregwebs gregwebs commented Jun 9, 2015

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 snoyberg modified the milestones: Later improvements, First stable release (0.1.0.0?) Jun 9, 2015
@snoyberg snoyberg self-assigned this Jun 15, 2015
@snoyberg
Copy link
Contributor Author

@snoyberg snoyberg commented Jun 15, 2015

Added in cf87169

@snoyberg snoyberg closed this Jun 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.