Quantcast

Tools to assist with development cycle of hackage packages

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tools to assist with development cycle of hackage packages

Clinton Mead
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:

  1. Initialise a repository on github
  2. Initialise git repository locally
  3. Set github repository as remote
  4. Add a LICENSE file
  5. Add a standard ".gitignore file"
  6. Create a cabal file with the appropriate files that hackage requires including:
    1. Git repository source
    2. Issues page
    3. Licence
    4. Licence file
  7. Run multi-ghc-travis to create a ".travis.yml" file
  8. Make an initial commit and push
  9. 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:

  1. Push to github
  2. Wait for Travis-CI to compile the package (this is a test to ensure it builds in a clean remote environment).
  3. Run "cabal sdist 2>&1"
  4. Parse the output of sdist to see where the dist file is.
  5. Run "hup packup fileFromSDist" to upload the package, putting in my hackage user/pass
  6. Run "hup docboth", to both build and upload the documentation.
  7. 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Adam Bergmark-2
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 <[hidden email]> 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:

  1. Initialise a repository on github
  2. Initialise git repository locally
  3. Set github repository as remote
  4. Add a LICENSE file
  5. Add a standard ".gitignore file"
  6. Create a cabal file with the appropriate files that hackage requires including:
    1. Git repository source
    2. Issues page
    3. Licence
    4. Licence file
  7. Run multi-ghc-travis to create a ".travis.yml" file
  8. Make an initial commit and push
  9. 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:

  1. Push to github
  2. Wait for Travis-CI to compile the package (this is a test to ensure it builds in a clean remote environment).
  3. Run "cabal sdist 2>&1"
  4. Parse the output of sdist to see where the dist file is.
  5. Run "hup packup fileFromSDist" to upload the package, putting in my hackage user/pass
  6. Run "hup docboth", to both build and upload the documentation.
  7. 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Sven Panne-2
2017-03-17 11:40 GMT+01:00 Adam Bergmark <[hidden email]>:
[...] 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
[...]

Just a small remark about this: IMHO this is a bit unfriendly to people checking out and building your package. They neither have your global ~/.gitignore-global nor your local repository configuration. So in my opinion .gitignore files really belong *into* any project, maintaining them is not really that hard...

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Clinton Mead
In reply to this post by Adam Bergmark-2
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 <[hidden email]> 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 <[hidden email]> 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:

  1. Initialise a repository on github
  2. Initialise git repository locally
  3. Set github repository as remote
  4. Add a LICENSE file
  5. Add a standard ".gitignore file"
  6. Create a cabal file with the appropriate files that hackage requires including:
    1. Git repository source
    2. Issues page
    3. Licence
    4. Licence file
  7. Run multi-ghc-travis to create a ".travis.yml" file
  8. Make an initial commit and push
  9. 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:

  1. Push to github
  2. Wait for Travis-CI to compile the package (this is a test to ensure it builds in a clean remote environment).
  3. Run "cabal sdist 2>&1"
  4. Parse the output of sdist to see where the dist file is.
  5. Run "hup packup fileFromSDist" to upload the package, putting in my hackage user/pass
  6. Run "hup docboth", to both build and upload the documentation.
  7. 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Ertugrul Söylemez-3
In reply to this post by Clinton Mead
> 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.

Yes.  Instead of creating a new repo, clone a template repo, then just
replace every instance of "SKELETON" by the new project's name -- a
script can do that.  Bonus: if you have to make a change to all your
projects, just change the template and then merge.

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

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Adam Bergmark-2
That's a very good idea, thanks!
On Fri, 17 Mar 2017 at 12:44, Ertugrul Söylemez <[hidden email]> wrote:
> 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.

Yes.  Instead of creating a new repo, clone a template repo, then just
replace every instance of "SKELETON" by the new project's name -- a
script can do that.  Bonus: if you have to make a change to all your
projects, just change the template and then merge.
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

David McBride
In reply to this post by Clinton Mead
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Brandon Allbery
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Clinton Mead
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tools to assist with development cycle of hackage packages

Sven Panne-2
2017-03-17 22:29 GMT+01:00 Clinton Mead <[hidden email]>:
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)

In the past it took several hours to build the docs, but I've got no recent numbers. How long it takes locally is largely irrelevant, the main problem on Hackage seemed to be the scheduling of the doc building task (or the absence of it ;-)...

Cheers,
   S.

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