Re: [Haskell-cafe] Handling absent maintainers
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
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 ber...@ukr.net 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
Re: [Haskell-cafe] Handling absent maintainers
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 mwot...@gmail.com 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 ber...@ukr.net 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton mwot...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
On Fri, Jul 16, 2010 at 11:49 AM, Jason Dagit da...@codersbase.com wrote: On Thu, Jul 15, 2010 at 5:54 PM, Mark Wotton mwot...@gmail.com 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling absent maintainers
Alexander Solla a...@2piix.com 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
