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@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@gmail.com> wrote:
> 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 <adam@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 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 that
>> 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@gmail.com> wrote:
>>>
>>> I've only just started uploading packages to hackage (my package 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 associatesunix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net