Handling absent maintainers

Mark Wotton

15 Jul 2010 15 Jul '10

8:54 p.m.

Hello all, I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our "one-world" approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it. I can think of a few ways to get around my current problems: 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though. 2. run my own hackage server and tell my users to use that instead. 3. ... profit? Ideally, I'd like to be able to say something like "cabal install my-hacked-package --as original-package" - are there fundamental reasons that wouldn't be possible, or a bad idea? mark

Show replies by date

Jason Dagit

15 Jul 15 Jul

9:49 p.m.

On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton wrote:

...

Hello all,

I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our "one-world" approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it.

I can think of a few ways to get around my current problems:

1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though.

2. run my own hackage server and tell my users to use that instead.

3. ... profit?

Ideally, I'd like to be able to say something like "cabal install my-hacked-package --as original-package" - are there fundamental reasons that wouldn't be possible, or a bad idea?

I haven't (yet) run into a completely AWOL maintainer. Usually I can contact the maintainer and offer to upload a new version for them. I'm currently in this role with Takusen. I'm not the Takusen maintainer, but I expect to be uploading the next version soon as it looks like I've been given permission. I've had this happen with a couple other packages and it was always a similar situation. Negotiate with the listed maintainer to do an upload on their behalf. I've found that offering to do the work for them usually helps tremendously. And it makes a lot of practical sense. Now, what you're proposing is interesting. I believe github/patch-tag have this model? Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies? On a philosophical note about cabal, cabal wants to be able to reason statically about the API (types, functions, modules) a package provides. So flags should primarily be used to configure platform specific bits necessary for compilation or implementation details, but not to change the API of a compiled library. From this point of view it seems to me that what your describing needs to be baked into either the package name or the version -- that is whatever cabal is going to look at during constraint satisfaction. I like your idea and I'd like to hear more about how we could accomplish it within the philosophical framework that cabal already has. Thanks, Jason

Alexander Solla

10:18 p.m.

On Jul 15, 2010, at 6:49 PM, Jason Dagit wrote:

...

Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies?

One thing cabal is missing is a... cabal to pick and choose APIs. Imagine: 1. Hackage-stable 2. Multiple Hackage-dev's, each based on current Hackage-stable (if they're too old, they're out of the running for inclusion in stable) Hackage-dev packages are submitted to the Hackage-stable Cabal, which picks and chooses the nicest code. Hackage-stable incorporates that code. The Cabal would be responsible for coordinating dependencies. (This would potentially involve some programming from members of the Cabal) This is kind of in line with how Haskell Platform is being built up. They take popular/useful packages with mature API's and promote them to the platform if there's enough interest.

Ivan Lazar Miljenovic

11:02 p.m.

Alexander Solla writes:

...

On Jul 15, 2010, at 6:49 PM, Jason Dagit wrote:

...
Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies?

One thing cabal is missing is a... cabal to pick and choose APIs.

Duncan Coutts keeps telling me that there's no such thing as the Haskell Cabal... ;-)

...

Imagine:

1. Hackage-stable 2. Multiple Hackage-dev's, each based on current Hackage-stable (if they're too old, they're out of the running for inclusion in stable)

Hackage-dev packages are submitted to the Hackage-stable Cabal, which picks and chooses the nicest code. Hackage-stable incorporates that code. The Cabal would be responsible for coordinating dependencies. (This would potentially involve some programming from members of the Cabal)

A few things I find that might not work with this approach: 1) Needs more manpower for people to vet each package; this could also be a problem when the person doing the vetting is good in the field of Haskell API design but might not be that versed in the problem domain, and thus might pick the version that has the better API solely from a programmers perspective rather than soemone that has to use that code. 2) Makes it difficult to write code depending upon quirks of an individual package, if the blessed API implementation gets changed. 3) How will we deal with a change in the choice (or even just the version) of the blessed implementation in terms of versioning of the API package? 4) For abstract libraries, you're constraining the creativity, etc. of package designers to meeting some abstract API design. This might work for new data structure implementations fitting into a class definition to be able to use pre-defined code, but I'm not sure how well it will work in terms of, say, an HTML templating library.

...

This is kind of in line with how Haskell Platform is being built up. They take popular/useful packages with mature API's and promote them to the platform if there's enough interest.

And this is partly a community-driven effort: the platform contains the libraries that seem to be used by the community (see Don's recent emails about getting some of the more popular Hackage packages into the Platform). Hackage 2.0 should also help in this regard with the promised availability of commenting/voting on packages. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Mark Wotton

10:46 p.m.

On Fri, Jul 16, 2010 at 11:49 AM, Jason Dagit wrote:

...

On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton wrote:

...
Ideally, I'd like to be able to say something like "cabal install my-hacked-package --as original-package" - are there fundamental reasons that wouldn't be possible, or a bad idea?

I haven't (yet) run into a completely AWOL maintainer. Usually I can contact the maintainer and offer to upload a new version for them. I'm currently in this role with Takusen. I'm not the Takusen maintainer, but I expect to be uploading the next version soon as it looks like I've been given permission. I've had this happen with a couple other packages and it was always a similar situation. Negotiate with the listed maintainer to do an upload on their behalf. I've found that offering to do the work for them usually helps tremendously. And it makes a lot of practical sense.

This is great when it works, but it does add friction on top of the process of forking and experimentation. One of the things I've noticed in myself is that I'm much more likely to try something out if I can fork it, make my changes and start using it right away (including distributing easily to other users). If I have to wait to go through the gatekeeper, motivation has to be very high. One of the interesting consequences of cheap forking is that projects like the emacs starter kit have a very different model: it's designed to be forked, and to have the user's personal changes committed, so you can stay up to date without having to extract everything into a small set of config files. This is more or less impossible under the cabal model.

...

Now, what you're proposing is interesting. I believe github/patch-tag have this model? Everyone has their own branch of everything they contribute to, listed right on the website? This is inline with another idea I've heard where we'd have a 'stable' hackage and 'unstable/dev' versions. But, how does this work for resolving and communicating dependencies?

In terms of Cabal? I don't know enough about it to be authoritative. Conceptually, it seems clear enough: if you specify a variant package explicitly by name, that one gets used - if you don't specify a variant, use the canonical package. So long as forking is cheap and not socially awkward, this is fine: you fork the chain of packages you need to show that it all works, and submit a pull request to the maintainer of the real package. If he doesn't like it, fine - you can still use your changed version. It might be nice to be able to mark a variant as no longer relevant once the changes have been pulled into the parent repo, but it's a frill.

...

On a philosophical note about cabal, cabal wants to be able to reason statically about the API (types, functions, modules) a package provides. So flags should primarily be used to configure platform specific bits necessary for compilation or implementation details, but not to change the API of a compiled library. From this point of view it seems to me that what your describing needs to be baked into either the package name or the version -- that is whatever cabal is going to look at during constraint satisfaction.

Yes, I tend to agree.

...

I like your idea and I'd like to hear more about how we could accomplish it within the philosophical framework that cabal already has.

Me too.:) mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Mark Wotton

17 Jul 17 Jul

10:02 p.m.

On Fri, Jul 16, 2010 at 10:54 AM, Mark Wotton wrote:

...

Hello all,

I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our "one-world" approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it.

I can think of a few ways to get around my current problems:

1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though.

I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Ben Millwood

3 Aug 3 Aug

11:36 a.m.

On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton wrote:

...

I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now.

mark

-- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :) Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead. I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something. So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package

Mark Wotton

4 Aug 4 Aug

11:23 p.m.

On Wed, Aug 4, 2010 at 1:36 AM, Ben Millwood wrote:

...

On Sun, Jul 18, 2010 at 3:02 AM, Mark Wotton wrote:

...
I've uploaded haskell-src-meta-mwotton, using the development version. It seems to work fine for my applications. It's a bit of a hack, but I can't think of a better way to do it for now.

mark

-- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

I've just come up against one of the drawbacks of this approach - having needed haskell-src-meta for a personal project, I downloaded the source and updated it to work with GHC 6.12, fixed various bits and bobs, and only now found out that much of that work had already been done elsewhere :)

Matt Morrow has been missing for a long time and I think it's reasonable to suppose he won't suddenly spring out of the darkness to fix things for us. I propose that someone just take up maintainership of the package. I am quite willing to do this with my version, or Mark if you think you'd like to keep a closer eye on your dependencies you could do it instead.

I further propose that we should write up a haskellwiki page about absent maintainers and what the community thinks is reasonable in terms of attempting contact before assuming them missing, presumed gone. This kind of depends also on how big an indignity we consider it to be if someone updates a package while the maintainer is just on holiday or something.

So we need to decide on: first, who will take haskell-src-meta, and second, what we think is good as a more general policy. I would think the process would go something like: 1. email maintainer, wait 2 weeks for reply 2. email cafe and maintainers of reverse dependencies with proposed changes, wait a week or so for people who know the maintainer to show up or other people to object to your changes 3. chomp package

I'm happy to let you do it, I don't understand much of the actual source. Not sure who's the grand gatekeeper of Hackage, though. Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Ivan Lazar Miljenovic

11:29 p.m.

On 5 August 2010 13:23, Mark Wotton wrote:

...

Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal.

Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3 Currently, AFAIK Hackage allows anyone with an account to upload anything. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Mark Wotton

11:32 p.m.

On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic wrote:

...

On 5 August 2010 13:23, Mark Wotton wrote:

...
Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal.

Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3

Currently, AFAIK Hackage allows anyone with an account to upload anything.

Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings. mark -- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Ivan Lazar Miljenovic

11:37 p.m.

On 5 August 2010 13:32, Mark Wotton wrote:

...

On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic wrote:

...
On 5 August 2010 13:23, Mark Wotton wrote:

...
Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal.

Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3

Currently, AFAIK Hackage allows anyone with an account to upload anything.

Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings.

Well, I'd like to see the code required to spontaneously create monkeys at an ethernet port, but from what I've read Hackage has no constraints in place in terms of who uploads what and when. You just can't upload something with a version that's already on Hackage. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Erik de Castro Lopo

5 Aug 5 Aug

12:07 a.m.

Ivan Lazar Miljenovic wrote:

...

On 5 August 2010 13:32, Mark Wotton wrote:

...
On Thu, Aug 5, 2010 at 1:29 PM, Ivan Lazar Miljenovic wrote:

...
On 5 August 2010 13:23, Mark Wotton wrote:

...
Might it be possible to enable multiple maintainers on packages, each of whom can upload new versions? As far as I can tell, that's not currently possible with Cabal.

Huh? Cabal doesn't care who the maintainers are: it just has a text field where you list a maintainer[s]. See for example http://hackage.haskell.org/package/fgl-5.4.2.3

Currently, AFAIK Hackage allows anyone with an account to upload anything.

Can you have two people uploading versions of the same package, though? Presumably it's not possible for me to upload a version of bytestring which makes monkeys fly out of your ethernet port when you try to concatenate strings.

Well, I'd like to see the code required to spontaneously create monkeys at an ethernet port, but from what I've read Hackage has no constraints in place in terms of who uploads what and when. You just can't upload something with a version that's already on Hackage.

The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust. The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

Ben Millwood

1:38 p.m.

On Thu, Aug 5, 2010 at 5:07 AM, Erik de Castro Lopo wrote:

...

The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust.

The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using.

Erik

It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them, and they can presumably just as easily be revoked. Thanks Mark, I'll request a Hackage account within the next couple of days and then make the upload.

Ben Millwood

1:39 p.m.

On Thu, Aug 5, 2010 at 6:38 PM, Ben Millwood wrote:

...

It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them

Er, to clarify, I mean signup can't be automated, because account creation is done by a human. Not that hackage charges for accounts or something.

Jonas Almström Duregård

17 Aug 17 Aug

5:30 a.m.

Hi, Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module. /Jonas On 5 August 2010 19:38, Ben Millwood wrote:

...

On Thu, Aug 5, 2010 at 5:07 AM, Erik de Castro Lopo wrote:

...
The permissiveness of hackage uploads suggests that Hackage needs to start using something like GPG signing and GPG webs of trust.

The Debian project has stuff like this in place and I'm sure this community could learn a lot from what Debian is currently using.

Erik

It's worth mentioning that Hackage accounts aren't just given out for free - one has to specifically request them, and they can presumably just as easily be revoked.

Thanks Mark, I'll request a Hackage account within the next couple of days and then make the upload. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ben Millwood

12:28 p.m.

2010/8/17 Jonas Almström Duregård :

...

Hi,

Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module.

/Jonas

Hi Jonas, Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload. I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2]. Yours, Ben Millwood [1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta

Geoffrey Mainland

6:43 p.m.

On 08/17/2010 12:28, Ben Millwood wrote:

...

2010/8/17 Jonas Almström Duregård :

...
Hi,

Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module.

/Jonas

Hi Jonas,

Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2].

Yours, Ben Millwood

[1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta

I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course. Geoff

Ben Millwood

18 Aug 18 Aug

2:25 a.m.

2010/8/17 Geoffrey Mainland :

...

On 08/17/2010 12:28, Ben Millwood wrote:

...
2010/8/17 Jonas Almström Duregård :

...
Hi,

Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module.

/Jonas

Hi Jonas,

Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2].

Yours, Ben Millwood

[1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta

I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course.

Geoff

I imagine maintaining compatibility across template-haskell versions might be tricky. Prior to template-haskell-2.4.0.0, I believe there was no TH support for kinds, and class contexts were simply Types rebranded (not supporting equality constraints). So some not-inconsiderable sections of code would need duplication, or we'd need to deal with CPP which always struck me as a fragile and inelegant solution. Of course, I welcome the patches to prove me wrong :) or well, if you just want to take maintainership yourself, the package is really as much yours as it is mine at this stage. Ben

Geoffrey Mainland

19 Aug 19 Aug

12:40 a.m.

On 08/18/2010 02:25, Ben Millwood wrote:

...

2010/8/17 Geoffrey Mainland :

...
On 08/17/2010 12:28, Ben Millwood wrote:

...
2010/8/17 Jonas Almström Duregård :

...
Hi,

Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module.

/Jonas

Hi Jonas,

Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2].

Yours, Ben Millwood

[1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta

I'm also waiting on a 6.12-compatible version of haskell-src-meta so I can release a version of my package for quasiquoting C/CUDA. I pulled Mark's changes to create a version that maintains compatibility with version 2.3 of the template-haskell library (and therefore with GHC 6.10). Is there any chance we can keep backwards-compatibility? ;) I'm happy to help with patches and/or maintainership, of course.

Geoff

I imagine maintaining compatibility across template-haskell versions might be tricky. Prior to template-haskell-2.4.0.0, I believe there was no TH support for kinds, and class contexts were simply Types rebranded (not supporting equality constraints). So some not-inconsiderable sections of code would need duplication, or we'd need to deal with CPP which always struck me as a fragile and inelegant solution. Of course, I welcome the patches to prove me wrong :) or well, if you just want to take maintainership yourself, the package is really as much yours as it is mine at this stage.

Ben

I have patches that main compatibility with 6.10, but now that haskell-src-meta depends of th-lift, which requires template-haskell>=2.4, I think it's a lost cause. Versioning for template-haskell makes things a real mess now---if I want a package using haskell-src-meta to work on both 6.10 and 6.12, I basically have to test the version of GHC being used and set package dependencies appropriately. Unless someone has a better way? Geoff

Jonas Almström Duregård

18 Aug 18 Aug

4:59 a.m.

...

I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I can upload a working .4 version of th-lift if needed, but I guess it might be undesirable to depend on it if 0.5 changes the API. I'll have a look at your version and see if I can merge my additions into it. For now, perhaps somebody should re-upload the current version of src-meta with the correct dependencies (TH<2.4)? 2010/8/17 Ben Millwood :

...

2010/8/17 Jonas Almström Duregård :

...
Hi,

Has there been any progress with this package? Like you I have also tried to contact Matt and like you I have ended up making my own version of src-meta :). When someone assumes maintainership of this package I would like to discuss integrating some additions I made to the Translation module.

/Jonas

Hi Jonas,

Sorry about the delay. In my version of haskell-src-meta I basically replaced the entire Language.Haskell.TH.Instances.Lift module with derivations from the th-lift package whose latest version currently doesn't build [1]. I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I suppose since there's no reason why I deserve maintainership more than you you could just go ahead and upload your version instead. You can see exactly what I've done at my github repository [2].

Yours, Ben Millwood

[1] http://hackage.haskell.org/package/th-lift-0.4 [2] http://github.com/benmachine/haskell-src-meta

Ben Millwood

9:49 p.m.

2010/8/18 Jonas Almström Duregård :

...

...
I had been in contact with the maintainer of the package who has prepared a version 0.5 and was waiting for them to upload it so that I could use it as a dependency, but I haven't heard from them in a week or so. I'll try emailing them again, and as soon as 0.5 is on hackage I will go ahead with my upload.

I can upload a working .4 version of th-lift if needed, but I guess it might be undesirable to depend on it if 0.5 changes the API.

I'll have a look at your version and see if I can merge my additions into it.

For now, perhaps somebody should re-upload the current version of src-meta with the correct dependencies (TH<2.4)?

Indeed I was using the th-lift 0.5 API changes; they're uploaded now so I went ahead with the haskell-src-meta 0.1.0 upload. I'll write up an announcement to the mailing lists soon. This is the first time I've ever maintained a haskell package, so I welcome all comments or suggestions! Ben

Roman Beslik

24 Jul 24 Jul

2:10 a.m.

I patch broken packages in my local repository. I increment a version so the local repository get a precedence over the Hackage. On 16.07.10 03:54, Mark Wotton wrote:

...

2. run my own hackage server and tell my users to use that instead.

-- Best regards, Roman Beslik.

Mark Wotton

2:36 a.m.

That works fine for my own stuff, but I'd like it to work for people using my software that relies on those packages. mark On Sat, Jul 24, 2010 at 4:10 PM, Roman Beslik wrote:

...

I patch broken packages in my local repository. I increment a version so the local repository get a precedence over the Hackage.

On 16.07.10 03:54, Mark Wotton wrote:

...
2. run my own hackage server and tell my users to use that instead.

-- Best regards, Roman Beslik.

-- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda

Alexander Dunlap

2:51 a.m.

One issue that comes up is that when you fork a package, data can no longer be freely exchanged between libraries using the original package's datatypes and libraries using the forked package's datatypes. Something that might help here is the concept of "extension" or "friend" packages or modules: packages or modules that could break through to access concrete representations of abstract datatypes or classes. The advantage would be that in many cases, instead of forking a package, you could make the necessary changes through a tightly-coupled but separately-maintained friend package while still maintaining compatibility with the original package. This wouldn't help for the problem of maintaining a package that wouldn't compile. That might be helped by something like a "provides" or "equivalent" field, where Cabal could be informed that a new package should be treated as satisfying a dependency on a different package. Alex On Fri, Jul 23, 2010 at 11:36 PM, Mark Wotton wrote:

...

That works fine for my own stuff, but I'd like it to work for people using my software that relies on those packages.

mark

On Sat, Jul 24, 2010 at 4:10 PM, Roman Beslik wrote:

...
I patch broken packages in my local repository. I increment a version so the local repository get a precedence over the Hackage.

On 16.07.10 03:54, Mark Wotton wrote:

...
2. run my own hackage server and tell my users to use that instead.

-- Best regards, Roman Beslik.

-- A UNIX signature isn't a return address, it's the ASCII equivalent of a black velvet clown painting. It's a rectangle of carets surrounding a quote from a literary giant of weeniedom like Heinlein or Dr. Who. -- Chris Maeda _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

5388

Age (days ago)

5422

Last active (days ago)

List overview

Download

23 comments

10 participants

participants (10)

Alexander Dunlap
Alexander Solla
Ben Millwood
Erik de Castro Lopo
Geoffrey Mainland
Ivan Lazar Miljenovic
Jason Dagit
Jonas Almström Duregård
Mark Wotton
Roman Beslik