Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 10:06 PM, Duncan Coutts wrote: Suppose both the zlib and tar packages specify build-depends: bytestring-0.9.*. It's entirely possible for me to install zlib, then upgrade to a new bugfix release of bytestring, install tar (using the new bytestring) and then build htar depending on tar+zlib. In this case none of the developers of these packages have done anything wrong. It is situations like this that cabal-install tries to avoid. Oh! Now I see. The impression that is coming to me now is that the package system is incredibly brittle, and so is very easy to break things even when theoretically following all of the rules. This isn't meant as a critique of the people who designed this system, mind you; it's works very well in practice for most things, and it is hard to see how these problems can be fixed without breaking other things. So I propose the following question to the floor: are there any ideas for changing the package system to make it less brittle? I think what you mean is that cabal-install should infer from the situation where package A needs 'C 2' and package B needs 'C= 2' that it is safe for a package to depend on both A and B and to be built indirectly depending on two versions of C. The fact that people can and often do make packages that work with either C 1 or 2 makes this situation less common. Also, it's not necessarily true, perhaps all it means is that the latest version of B now needs a later C and so my package now cannot use that later version of C because it did indeed pass values of types defined in C between functions defined in A and B (that is, my package has been busted by the latest release of B). Okay, I see now why it's harder then I had figured it would be. Thank you for taking the time to explain to me why I was wrong. :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. The only problem I've had is with cabal, which when resolving dependencies seems to only be able to pick out one version of a package; in some cases instead of running cabal install A B where A and B depended on different versions of the same package (QuickCheck) I had to instead separately run cabal install A and cabal install B. This isn't a big deal, but I could imagine cases where it could fail to automatically install a package entirely due to conflicting version requirements. This, however, is not because there is an intrinsic problem with installing multiple versions of a library, but simply because cabal sometimes seems to get confused about what it needs to do. cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. I suppose where we differ is in how big of a concern we view 'just cabal having a problem with it' is. All I can say is that every time there has been a major API change where half the community hasn't moved, it has been a practical problem. It become yet another implementation detail that every subsequent developer has needed to consider, and providing support and instances for both is impractical. So while in theory, just bumping the major version number would be sufficient, in practice, I think picking a new package name and namespace would: * fit more closely with the spirit of a ground-up redesign * allow it to succeed or fail on its own merits * avoid torturing new users with cabal install warnings they won't understand * allow libraries that want or need to be agnostic with respect to the change the ability to provide instances for both libraries, providing a smoother upgrade path for their users. Which in the end, seems to be a net positive over: * requiring folks to use one version of fgl entirely internally without exposing it through their API or splinter their user base * causing cabal to panic * ultimately adding yet another hack to the hackage config which indicates implied upper bounds on the stable version of the package, since the current fgl is part of the haskell platform and the new design will not be stable for some time If fgl wasn't part of the haskell platform or the changes were less radical, the balance of net good might go the other way. -Edward Kmett ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 2:13 PM, Edward Kmett wrote: On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu mailto:gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. Yes, but if details of the package you are using are leaking out into the interface then you will have the same kind of problems whenever that package conflicts with any other package, regardless of whether the conflict is with a package of the same name. For example, for a while there was a conflict between mtl and transformers because they shared a package name, and the fact that the two packages had different names didn't make the problem any better. The only problem I've had is with cabal, which when resolving dependencies seems to only be able to pick out one version of a package; in some cases instead of running cabal install A B where A and B depended on different versions of the same package (QuickCheck) I had to instead separately run cabal install A and cabal install B. This isn't a big deal, but I could imagine cases where it could fail to automatically install a package entirely due to conflicting version requirements. This, however, is not because there is an intrinsic problem with installing multiple versions of a library, but simply because cabal sometimes seems to get confused about what it needs to do. cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. I suppose where we differ is in how big of a concern we view 'just cabal having a problem with it' is. All I can say is that every time there has been a major API change where half the community hasn't moved, it has been a practical problem. It become yet another implementation detail that every subsequent developer has needed to consider, and providing support and instances for both is impractical. My point isn't that it is not a big deal that cabal has a problem with it, it is that this is something that we should fix *in cabal* since there is nothing intrinsically intractable about it. Furthermore, the kinds of problems that people encounter in such transitions won't be fixed merely by changing the name of the package since conflicts can still appear with the old package. If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Wed, Jun 23, 2010 at 2:57 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On 6/23/10 2:13 PM, Edward Kmett wrote: On Tue, Jun 22, 2010 at 4:54 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. This works fine as long as no detail of the embedded library leaks into the public API. QuickCheck is typically the least painful library to mix, since you don't typically use the quickcheck properties from multiple quickcheck versions drawn from other packages at runtime. Yes, but if details of the package you are using are leaking out into the interface then you will have the same kind of problems whenever that package conflicts with any other package, regardless of whether the conflict is with a package of the same name. For example, for a while there was a conflict between mtl and transformers because they shared a package name, and the fact that the two packages had different names didn't make the problem any better. Yes, and that problem still isn't resolved in another since, since they share the same module names, but as of yet, still provide an incompatible API. I can't (yet) provide 'RightSemiNearRing' instances that work with both the monad transformers from transformers and mtl without deep mojo. The resolution there seems to be to bring transformers and mtl into close enough alignment that we'll be able to finally release a version of the mtl that just imports transformers and monads-fd, and provide a set of guidelines about the fact that in the switch to the next major version of mtl, the non-transformer versions of the monad-transformer stack are just type aliases. In that case the APIs are close enough that with a few breaking changes to existing users on each side, the APIs can be reconciled and the community unfractured. That said, we've had this plan waiting in the wings for months. ;) But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. This becomes somewhat tricky. You can do this more or less with data types and classes, but with instances it is less clear how to do so. Instances (necessarily) kind of silently infect your public interface, and so this form of reasoning is at best global, not local. There has been some chatter about splitting up build dependencies into internal and external dependencies, although I don't know how serious it was, but that would be a move in this direction. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Regardless, it is unlikely to be fixed before Ivan goes to release his shiny new type-family-driven FGL. =) So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. [...] If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional benefit to also renaming the package. Actually, once you've given them different module names keeping the same package name _is_ an impediment. Because with different package names you could import both and provide instances for both, say, fgl's Graph, and for Ivan's very different type-family driven Graph, but you needlessly sacrifice that upgrade path for your users if you force both packages to have the same name. Another very different consideration is that
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 3:29 PM, Edward Kmett wrote: Yes, and that problem still isn't resolved in another since, since they share the same module names, but as of yet, still provide an incompatible API. I can't (yet) provide 'RightSemiNearRing' instances that work with both the monad transformers from transformers and mtl without deep mojo. The resolution there seems to be to bring transformers and mtl into close enough alignment that we'll be able to finally release a version of the mtl that just imports transformers and monads-fd, and provide a set of guidelines about the fact that in the switch to the next major version of mtl, the non-transformer versions of the monad-transformer stack are just type aliases. In that case the APIs are close enough that with a few breaking changes to existing users on each side, the APIs can be reconciled and the community unfractured. That said, we've had this plan waiting in the wings for months. ;) Oh, cool, so that's the plan? Grr, if I had fewer projects I would volunteer to help out with this. :-) But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. This becomes somewhat tricky. You can do this more or less with data types and classes, but with instances it is less clear how to do so. Instances (necessarily) kind of silently infect your public interface, and so this form of reasoning is at best global, not local. There has been some chatter about splitting up build dependencies into internal and external dependencies, although I don't know how serious it was, but that would be a move in this direction. But does cabal even need to do an analysis that is that sophisticated? All it needs to see are the package dependencies in order to note that, Oh, this package requires version X, and this package requires version Y, so therefore I need to install both! rather than saying, Hold on, these two packages require *different versions* of the same package? I give up! And conflicts between instances and things need to be taken care of before the package can even be built, let alone uploaded to Hackage. So while I agree that these are problems, they are not really cabal's problem to worry about since by the time cabal has been brought into the picture they must have already been resolved. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Regardless, it is unlikely to be fixed before Ivan goes to release his shiny new type-family-driven FGL. =) Fair point. :-) So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. There are multiple potential implementation semantics that can be assigned to a diamond dependency. The types could be incompatible. They could be compatible, and the most recent version should be used by all (in case of minor API changes). They could be somewhere in between. Yes, but again this will happen whenever you use two packages that conflict, regardless of whether they just happen to have the same name or not, as it did for a while with mtl and transformers. Renaming fgl to newfgl won't actually make this situation any better. [...] If we really are worried so much about these kinds of conflicts, then the real solution is to make sure that none of the modules exported by the new package share the same name as the modules in the old package. And if one is going to do that anyway, then from the perspective of resolving conflicts there isn't any additional benefit to also renaming the package. Actually, once you've given them different module names keeping the same package name _is_ an impediment. Because with different package names you could import both and provide instances for both, say, fgl's Graph, and for Ivan's very different type-family driven Graph, but you needlessly sacrifice that upgrade path for your users if you force both packages to have the same name. Okay, so the assumption is that although dependencies could use different versions of a package with the same name, when you yourself use a package you can only use one particular version of the package. Given this assumption I see your point, though perhaps it would be a good idea to allow package imports to also allow
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Edward Kmett ekm...@gmail.com writes: One much weaker consideration is that out of the 23+ direct dependencies on fgl, fully half of them don't bother to specify an upper bound on the fgl version and would break immediately. That said, those packages are out of compliance with package versioning policy. =) I've contacted all the maintainers of those packages, and have received replies from all but two maintainers promising to fix theirs (still haven't heard from Aditya Mahajan for teams and John Morrice for esotericbot). Note that I'm just as guilty in this regard as I have three packages that depend on fgl without upper bounds... _ I don't know how many of them have released fixed versions yet (I know I haven't), but with the whole two versions of FGL needed thing: we're going to work hard to help maintainers of packages that use FGL to upgrade to the new version once we're satisfied with it and decide to make the release official. As such, we shouldn't have any problems of packages depending transitively on two versions of FGL because most if not all of them will get upgraded. With FGL, we also have the situation where we have a famous library that isn't actually used much: * Out of those 23 direct dependencies on Hackage, 3 of them were by old versions of packages (i.e. they no longer use fgl); these are mpc, jhc and lhc. * One is officially deprecated (scenegraph). * 10 are pure libraries (note that some of these have no reverse dependencies, or if they do it's only by a few packages) (note that I included a package here if its executable seemed to only be for tests). * 6 are executables only. * 3 seem to be a library + an executable; only one of these has a reverse dependency and even then by one other package. Out of the 25 indirect reverse dependencies: * 20 (some of which are older versions only and thus not the latest) may transitively depend upon the old version of mps (either directly or via the hack library); because the dependencies on mps, etc. are open-ended for many of these it's difficult to tell if a new install will still transitively require fgl (as in to actually get it to work). * 1 dependency on cabal-macosx * 2 dependencies on lambdacube-engine (other lambdacube projects) * 2 satchmo projects depending (transitively in one case) upon funsat. As such, if we only consider transitive dependencies, then this issue of one package using new and another old fgl is a non-issue as in all cases as there's only a single point of contact with fgl. From what I can tell, fgl is more often used for internal projects or executables rather than to create actual libraries. So the whole problem of worrying about multiple versions appears to be (no offense to anyone) scare-mongering (or looking for possible problems due to bad experiences with parsec, etc.). With the 4 transitive dependencies on fgl above, I'm not sure how many of them actually see any aspects of fgl or if its all hidden inside the internal API of whatever package they use. Thus, once packages have proper reverse dependencies in their .cabal files (as they should), then we should not really have a problem here if a few packages don't upgrade at the same time or at all (except for cases where a distribution only ships one version of each library and wants to ship two different packages that depend upon different versions of fgl). Once again: we're going to do our very best to avoid the issues that arose when parsec, QuickCheck, etc. had new major versions released and packages transitively depended upon two different versions; however if it does arise then it's going to be a very small localised problem. -- 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
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 23 June 2010 19:57, Gregory Crosswhite gcr...@phys.washington.edu wrote: cabal is the only mechanism that the vast majority of Haskell-users know how to use these days. Resolving diamond dependencies safely relies on knowing tha tthe use of different libraries is entirely internal to the library in question -- a detail that is not currently exposed through the cabal file. You can use PackageImports to try and hack around common package names at least in GHC, but it then further confuses purpose and provenance. But cabal can see with exactly which packages each of the dependencies requires, right? So what is stopping it from just walking through the dependencies and constructing the dependency graph? It should have all of the information it needs to do this. To the extent that the full information that cabal needs exists and yet it is not capable of recognizing this, I would view this as a bug in cabal that we should fix, rather than deciding just to live with this bug and limiting ourselves to a subset of the package dependency functionality. Actually cabal-install does not have enough information to distinguish when the diamond dependencies are definitely safe and where they might be unsafe. Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. In this situation it is essential that the tar and zlib packages share exactly the same version of the bytestring package. If they do not then we will get a type error when compiling the htar program. Now another example where using two versions of a dependency would be ok: Suppose the tar and zlib packages have QC tests in the library but they are not exported. It would be fine to have the two using different versions of the QC package, they could not interfere because no types from QC are passed between the two packages. However, as far as Cabal is concerned these two situations are indistinguishable. Cabal does not have enough information to tell them apart. It does not know that the QC deps are private, it must assume the worst. If it did know that some deps were private then in principle we could do better. In the medium term I would like to see private dependencies added to the .cabal package description and to have that used by cabal-install (it'd also have to be enforced). In the mean time, I suggest continuing to make new major versions of packages as normal. The tools will eventually catch up. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On 6/23/10 8:06 PM, Duncan Coutts wrote: Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. Okay, I hadn't considered this, though it seems like the real problem in this situation is that someone violated the package version policy: if tar is upgraded to use a newer, incompatible version of bytestring, then it should have an appropriate version bump that causes htar to ignore the new version and use the older version instead. I am getting the impression from these discussions that what we really need in the long term to solve a lot of these problems is to enforce the package versioning policy. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Wed, 2010-06-23 at 21:05 -0400, Gregory Crosswhite wrote: On 6/23/10 8:06 PM, Duncan Coutts wrote: Consider an example where we want to avoid using two versions of a dependency: The htar program depends on the tar and zlib packages. The tar and zlib packages depend on bytestring. Both tar and zlib export functions that use the type ByteString. The htar program takes composes functions from the two packages together, passing a bytestring from one to the other. Okay, I hadn't considered this, though it seems like the real problem in this situation is that someone violated the package version policy: if tar is upgraded to use a newer, incompatible version of bytestring, then it should have an appropriate version bump that causes htar to ignore the new version and use the older version instead. It's nothing to do with a version policy. Letting people opt-in and then enforcing a package versioning policy would be great, but it is orthogonal to this problem. Suppose both the zlib and tar packages specify build-depends: bytestring-0.9.*. It's entirely possible for me to install zlib, then upgrade to a new bugfix release of bytestring, install tar (using the new bytestring) and then build htar depending on tar+zlib. In this case none of the developers of these packages have done anything wrong. It is situations like this that cabal-install tries to avoid. You could construct similar examples involving major versions rather than bugfix versions. All you need is for someone to have tested with two major versions and to mark their package as being able to work with either. I think what you mean is that cabal-install should infer from the situation where package A needs 'C 2' and package B needs 'C = 2' that it is safe for a package to depend on both A and B and to be built indirectly depending on two versions of C. The fact that people can and often do make packages that work with either C 1 or 2 makes this situation less common. Also, it's not necessarily true, perhaps all it means is that the latest version of B now needs a later C and so my package now cannot use that later version of C because it did indeed pass values of types defined in C between functions defined in A and B (that is, my package has been busted by the latest release of B). Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 08, 2010 at 11:21:54AM -0700, Gregory Crosswhite wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Until some package you rely on decides to upgrade and start using fgl-6 internally without modifying its external API. Suddenly you are incompatible without a version number bump anywhere due to a completely non-local change. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
The problem is that nothing breaks immediately. Then someone else comes along and transitively depends on your package and on another package, which depends on the newer version. Your users wind up with strange conflicts like that if they are using Parsec 3 they can't use HTTP. Or if they use fc-labels they can't use any library that internally uses mtl, because fc-labels uses transformers. Or worse they want to use a library that used fc-labels internally with another library that used mtl internally. It fragments the library base that you are able to use. Version caps are not the answer. -Edward Kmett On Tue, Jun 8, 2010 at 2:21 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg On Jun 8, 2010, at 11:08 AM, Gene A wrote: On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
There is no reason that your program couldn't link to multiple versions of the same package so that each library can access the version that it needs. In fact, GHC already does this, doesn't it? For example, I use a mixture of libraries in my programs that link to QuickCheck 1 and QuickCheck 2, and this works just fine. The only problem I've had is with cabal, which when resolving dependencies seems to only be able to pick out one version of a package; in some cases instead of running cabal install A B where A and B depended on different versions of the same package (QuickCheck) I had to instead separately run cabal install A and cabal install B. This isn't a big deal, but I could imagine cases where it could fail to automatically install a package entirely due to conflicting version requirements. This, however, is not because there is an intrinsic problem with installing multiple versions of a library, but simply because cabal sometimes seems to get confused about what it needs to do. So in short, I see no problem with there being multiple versions of a package floating around, and to the extent that an implementation of something can't handle this it seems like this is arguably a bug in that implementation rather than a bug in the package system for allowing the possibility. Cheers, Greg On 6/22/10 4:06 PM, Edward Kmett wrote: The problem is that nothing breaks immediately. Then someone else comes along and transitively depends on your package and on another package, which depends on the newer version. Your users wind up with strange conflicts like that if they are using Parsec 3 they can't use HTTP. Or if they use fc-labels they can't use any library that internally uses mtl, because fc-labels uses transformers. Or worse they want to use a library that used fc-labels internally with another library that used mtl internally. It fragments the library base that you are able to use. Version caps are not the answer. -Edward Kmett On Tue, Jun 8, 2010 at 2:21 PM, Gregory Crosswhite gcr...@phys.washington.edu mailto:gcr...@phys.washington.edu wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg On Jun 8, 2010, at 11:08 AM, Gene A wrote: On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com mailto:d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg On Jun 8, 2010, at 11:08 AM, Gene A wrote: On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ 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] Rewriting a famous library and using the same name: pros and cons
On Tuesday 08 June 2010 20:21:54, Gregory Crosswhite wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg Right. At least, nothing breaks until the next compiler release makes the old library break. But a new package name wouldn't help with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Gene A yumag...@gmail.com writes: Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! So as soon as you write the basics of an API you can never change it, just extend it to avoid making people have to re-write their code that uses it? That road leads down the path of complacency and stagnation IMHO... -- 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
