Re: Adding tests for cabal-install
Jason Dagit dag...@gmail.com writes: [...] The risk of using the cabal-install modules as a library is that the API of cabal-install should be allowed to change freely between versions, potentially causing breakages in downstream tools. I think if that risk is understood by consumers of the API then it's actually really valuable to have that level of access to the internals. well, that's what the PVP is there for... if consumere adhere to the PVP they won't break compilation due to API changes... :-) ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Adding tests for cabal-install
Hi, Splitting out a library from cabal-install have been a goal for a long time. I don't know if we want to just expose every module that's there today or if we'd like to think a bit more about the API first. Duncan, what do you think? -- Johan On Sun, Dec 30, 2012 at 7:09 PM, Mikhail Glushenkov the.dead.shall.r...@gmail.com wrote: Hi all, I'm currently looking into #1159, and I'd really like to add some unit tests for the UserConstraints parser. The problem is that I can't access modules defined under Distribution.Client.* without doing unnecessary recompilation. Would it be fine if I split cabal-install into library and executable parts in the following fashion: Library cabal-install Build-depends: ... ... Executable cabal-install Main-is: Main.hs Build-depends: cabal-install == N.N, ... ... Test-suite unit-tests Build-depends: cabal-install == N.N, ... ... -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Adding tests for cabal-install
Hi, On Mon, Dec 31, 2012 at 3:56 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi, Splitting out a library from cabal-install have been a goal for a long time. I don't know if we want to just expose every module that's there today or if we'd like to think a bit more about the API first. We'll have to expose every module for which we want to write tests anyway. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Adding tests for cabal-install
The test-suite section can mention the modules directly if we accept some recompilation. On Monday, December 31, 2012, Mikhail Glushenkov wrote: Hi, On Mon, Dec 31, 2012 at 3:56 PM, Johan Tibell johan.tib...@gmail.comjavascript:; wrote: Hi, Splitting out a library from cabal-install have been a goal for a long time. I don't know if we want to just expose every module that's there today or if we'd like to think a bit more about the API first. We'll have to expose every module for which we want to write tests anyway. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Adding tests for cabal-install
Hi Johan, On Tue, Jan 1, 2013 at 7:33 AM, Johan Tibell johan.tib...@gmail.com wrote: The test-suite section can mention the modules directly if we accept some recompilation. Correct, but I want to avoid unnecessary recompilation (as I said in my first message). If we're willing to accept it, though, we don't actually need to make cabal-install a library. -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
Re: Adding tests for cabal-install
On Mon, Dec 31, 2012 at 6:56 AM, Johan Tibell johan.tib...@gmail.comwrote: Hi, Splitting out a library from cabal-install have been a goal for a long time. I don't know if we want to just expose every module that's there today or if we'd like to think a bit more about the API first. Duncan, what do you think? I'm not Duncan, but I'll give my perspective on this. The API will get versioned due to the nature of cabal packages and having more access would be helpful for tools like cabal-dev. In an ideal world cabal-dev would/will go away, but other tools that build on cabal-install might appear in the future. The risk of using the cabal-install modules as a library is that the API of cabal-install should be allowed to change freely between versions, potentially causing breakages in downstream tools. I think if that risk is understood by consumers of the API then it's actually really valuable to have that level of access to the internals. Basically, I'm +1 on making all of cabal-install into a library. Jason ___ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
