Make n2o.cabal hackage-proof

[nponeccop]

• Separate n2o-chat ( Move chat sample to a separate Cabal project #48 )
• Test n2o dependency in Travis ( Test -package n2o in Travis #29 )
• Haddock the Haskell API ( Haddock API documentation #31 )
• Haddock Browser-side HTML injection API ( guidelines for HTML injection #24 )
• Ensure n2o-chat sdist works ( Fully functional cabal sdist in n2o-chat #23 )
• Upload to hackage ( Upload to Hackage #21 )

[nponeccop]

cabal sdist works now, but the the Hackage library tarball should not contain the sample. Also Hackage has its own validation process so we should pass it too for this bug to be closed

[5HT]

why should not? where it does state?

[nponeccop]

The main reason is that having chat inside the package doesn't make end-user workflow any simpler. Imagine a quickstart instruction when N2O is on hackage.

The user basically needs:

• a .cabal file for the haskell part, with n2o as a dependency
• a document root with index.html, index.css and client.js (user's client code and third-party libraries. Think of d3.js, paper or whatever)
• a way to expose N2O *.js via HTTP
• a way to expose the document root via HTTP
• a way to update *.js whenever N2O is improved

A common solution for all of the above is scaffolding - providing a tool to create all of those for fresh projects.

I was thinking of something like cabal unpack n2o-scaffold-chat or cabal unpack n2o-scaffold-empty for a poor-man version of scaffolding (e.g. no updating). But it's still serves its purpose as no git or manual getting of tarballs is required. And we can have as many scaffolds as we wish, including third-party scaffolds like n2o-scaffold-bower with upstream n2o and third-party libraries sitting in bower_components, a minified scaffold, a scaffold with nginx config included and so on.

The point is that cabal unpack n2o serves the purpose of scaffolding rather poorly because it's polluted with n2o proper.

There is a subproblem is that production requires a separate .cabal for user project. So if a user wants to patch the chat incrementally until it becomes the user project, at some point he needs to split the .cabal.

Another problem is that the upstream n2o is not included in the tarball now: Readme.md and LICENSE are the only non-haskell files.

As for your question, shipping samples within the sdist or outside of it is not regulated. It seems hackage has both ways. So we are only guided by simplicity for our users. My argument is that the current removal of n2o proper and splitting .cabal is hardly any easier for a user than cabal unpack solution that I propose.