[Haskell-cafe] Tools to assist with development cycle of hackage packages
clintonmead at gmail.com
Fri Mar 17 21:29:55 UTC 2017
Doc building didn't work for me about two weeks ago, although I only waited
for above half an hour. Have things improved since then, or was I just not
patient enough? (these are for docs that take seconds to build locally)
On Sat, 18 Mar 2017 at 2:28 am, Brandon Allbery <allbery.b at gmail.com> wrote:
> Hackage doc building was broken for close to a year, and a lot of people
> seem to have concluded that it is therefore permanently broken. But quite a
> lot of work was put into (a) fixing problems (b) adding monitoring so the
> problems can be detected quickly and fixed if they recur; it's been working
> for at least 6 months now, and seems fairly stable.
> (That said, at this point I will not be surprised if the consensus of the
> community is "no no it is broken forever! always work around it!")
> On Fri, Mar 17, 2017 at 8:18 AM, David McBride <toad3k at gmail.com> wrote:
> Stack upload doesn't seem to upload docs itself. But hackage seemed
> to build docs for my project without much of a hitch. I know that it
> has been backed up at some points in the past, but as of yesterday it
> seems to be working fine.
> On Fri, Mar 17, 2017 at 7:29 AM, Clinton Mead <clintonmead at gmail.com>
> > Does "stack upload" build and upload the docs or will I still need "hup"
> > that?
> > On Fri, 17 Mar 2017 at 9:40 pm, Adam Bergmark <adam at bergmark.nl> wrote:
> >> The stack templates are quite nice. The default is missing #1 #5 #6.2 #7
> >> #8 #9. Setting up external services is of course a bit more involved but
> >> maybe that can be added to an external tool extending stack? But dot
> ask the
> >> stack maintainers as well for their opinion! The others I think should
> >> fine to add, possibly as options. But I haven't looked into customizing
> >> templates or much other than the default template so maybe some of this
> >> already in there somewhere.
> >> I'm slowly moving away from local .gitignore files, in ~/.gitconfig you
> >> can ignoring globally by specify e.g.
> >> [core]
> >> excludesfile = /Users/adam.bergmark/.gitignore-global
> >> `stack upload` does sdist + upload and can store your hackage
> >> Sounds like hup or a tool extending it might be a good starting place to
> >> do take care of the release process. I'd for instance want it to check
> >> the travis build for the tag (or commit hash which would happen first)
> >> succeeded before uploading. I'm not aware of other work in this area
> but I
> >> haven't looked.
> >> Cheers,
> >> Adam
> >> On Fri, 17 Mar 2017 at 11:17 Clinton Mead <clintonmead at gmail.com>
> >>> I've only just started uploading packages to hackage (my package
> >>> is here) but currently there's a lot of repetitive activities for
> >>> and updating packages.
> >>> For example, here's the steps in creating a package:
> >>> Initialise a repository on github
> >>> Initialise git repository locally
> >>> Set github repository as remote
> >>> Add a LICENSE file
> >>> Add a standard ".gitignore file"
> >>> Create a cabal file with the appropriate files that hackage requires
> >>> including:
> >>> Git repository source
> >>> Issues page
> >>> Licence
> >>> Licence file
> >>> Run multi-ghc-travis to create a ".travis.yml" file
> >>> Make an initial commit and push
> >>> Refresh travis-ci.org's repository list so it detects the new
> >>> There's also the stack stuff, but the GUI I'm using, IntelliJ with a
> >>> Haskell plugin, handles most of that. It also creates a cabal file,
> but it's
> >>> missing a number of key fields as mentioned above.
> >>> When I actually want to upload the package I go though these steps:
> >>> Push to github
> >>> Wait for Travis-CI to compile the package (this is a test to ensure it
> >>> builds in a clean remote environment).
> >>> Run "cabal sdist 2>&1"
> >>> Parse the output of sdist to see where the dist file is.
> >>> Run "hup packup fileFromSDist" to upload the package, putting in my
> >>> hackage user/pass
> >>> Run "hup docboth", to both build and upload the documentation.
> >>> Tag the commit as a release
> >>> Currently, I've got two scripts with help with a lot of this, but it's
> >>> bit adhoc, and it's not fully automated (for example, I still have to
> >>> manually ensure all the correct fields are in the cabal file, usually
> >>> copy/pasting from another package and modifying).
> >>> Are there any tools that I haven't found that make this process a bit
> >>> more painless? I'm a bit new to this area, and I've only started using
> >>> recently as a prelude to uploading my Haskell packages, so admittedly
> I may
> >>> have missed something obvious or perhaps I'm just doing it all wrong.
> >>> But if other people do find it painful like me, perhaps I'll put some
> >>> effort into rewriting my perl scripts into nice haskell packages and
> >>> executables for others to use.
> >>> _______________________________________________
> >>> Haskell-Cafe mailing list
> >>> To (un)subscribe, modify options or view archives go to:
> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>> Only members subscribed via the mailman list are allowed to post.
> > _______________________________________________
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> Only members subscribed via the mailman list are allowed to post.
> brandon s allbery kf8nh sine nomine
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe