Re: [Haskell-cafe] Tools to assist with development cycle of hackage packages

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 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 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.

...

Does "stack upload" build and upload the docs or will I still need "hup" for that?

On Fri, 17 Mar 2017 at 9:40 pm, Adam Bergmark 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 be 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 is 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 credentials.

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 wrote:

...

I've only just started uploading packages to hackage (my package

On Fri, Mar 17, 2017 at 7:29 AM, Clinton Mead wrote: that listing

...

...

...

is here) but currently there's a lot of repetitive activities for creating 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 repository

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 a 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 by 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 git 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: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net