Excerpts from Oleg Grenrus's message of 2016-07-14 02:08:54 -0700: > About convenience libraries I agree even more. We should discussed them more. > There are questions I’d might to ask, but I guess it too late
It's not too late. They are not in any real release. They can be removed. > Or maybe not too late, but for another thread: > what is convenience library name clashes with the library on package, > say I define convenience library fancylib-lens, which is on Hackage, but > maybe also after I made my package? > I guess, some shadowing happens? Is there a warning? Convenience library shadows the one on Hackage. There's no warning but it would be easy to add one; however, I don't think there should be a warning--these names are just lexically scoped. > But we have quite formal feeling proposals about `provides`, > and `or-dependencies / multi-way-flag / depends`, and > formal process would help to get them thru (or say no, with an explanation) Yes. Especially when there are competing solutions and there is not an obvious "best one". > About the original topic, I’d require “ a history of quality contributions”, > so something between (2) or (3). > I don’t like many rules, also making fair but non-abusable ones is difficult, > but as we have this conversation, > the outcome should be well defined (also how we change the rules). > As with (2) does every accepted PR counts, like single character typo fix in > the documentation? > And I don’t know how to define “quality contribution” :( In the blog post linked, the suggestion was to apply discretion by looking at the GitHub profile / erstwhile contribution history. But yes, I DO think we should accept single character typo fixes! That's how you get new contributors who help spruce up the documentation. We should trust but verify. > (Maybe I’m just to scared about dramas happened elsewhere) Too late; there's already drama ;) > Related to this, a thought I had for some time: > I’d like to split Cabal and cabal-install repositories. > > Pros: > - `cabal-install` can be much more liberal in giving out commit bits, as you > cannot make too much damage here. > - we already have `hackage-security` as a dependency between them. > - the CI setup could be simplified, resulting into > - their tests could do more things: `Cabal` parses all `Hackage`, changes to > `cabal-install` doesn’t need to do it, > and vice-versa, fixing ui of cabal-install doesn’t need to do package tests > of Cabal. > - their other processes could be different too. > > Cons: Simultaneous development is almost impossible. And this is almost a > show-stopper. > - `cabal-install` would need to lag one release behind `Cabal` (development > agains released `Cabal`). > This could work as `Setup.hs` should work to install packages requiring > newer Cabal (isn’t it how it works nowadays?). > There will be a problem when newer `Cabal` won’t accept build-plan created > by solver > in older `cabal-install` (proposals mentioned above), but I hope it won’t > be a huge issue. > - To make this work we’d need to release more Cabal major versions, > so there aren’t many breaking and intrusive changes accumulating. But > that’s good thing, isn’t it? > > Or it could be a quality win to separate them. After all `cabal-install` is > not the only consumer of `Cabal`. > `stack` uses it very limitedly atm though (i.e. to extract dependencies and > maybe verify install plan?) > I don’t know what `ghc-pkg` does. > > IMHO we should develop Cabal-the-library with highest standards (starting > with having detailed CHANGELOG) for library development. > Now we might have been too focused on developing Cabal for cabal-install. > Cabal should provide quality plumbing support for “everyone”. > (if we could start with a clean desk, i’d make Setup.hs and cabal-install > commands different, that’s one confusing part). > > The separation into different repositories would make things a bit clearer: > Cabal-the-library and cabal-install are different things. (For example: > cabal-install doesn’t parse *.cabal files). Currently cabal-install is tightly coupled to Cabal. I'm all for looser coupling (e.g., https://github.com/haskell/cabal/issues/3549). Separate repositories force this, but in general looser coupling will lead to some short term pain. Edward _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
