Comments on: Simple Cabal parsing http://therning.org/magnus/archives/514 Incoherent mumblings Tue, 24 Aug 2010 06:00:57 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Magnus http://therning.org/magnus/archives/514/comment-page-1#comment-171426 Magnus Thu, 26 Feb 2009 15:43:49 +0000 http://therning.org/magnus/?p=514#comment-171426 <p>@Duncan, thanks, that <em>does</em> clarify it a bit. Not that simple though ;-)</p> @Duncan, thanks, that does clarify it a bit. Not that simple though ;-)

]]> By: Duncan http://therning.org/magnus/archives/514/comment-page-1#comment-171422 Duncan Thu, 26 Feb 2009 14:03:02 +0000 http://therning.org/magnus/?p=514#comment-171422 <p>Just to clarify...</p> <p>When you call finalizePackageDescription you get to say something about flag values. You can specify true or false or you can not specify it at all. Then finalizePackageDescription will come up with true/false values for the flags that you did not specify. It does this based on the default values for the flags (given in the .cabal file by the package author) but more interestingly based on the possible flag values given the flag-conditional dependencies and the set of available packages. Now you're not specifying any set of available packages (not the same as specifying none, then we could not finalise any package). So all constraints (that are not self-contradictory) will be presumed to be ok.</p> <p>The result is that (since you use Nothing for the set of available packages) you're getting the default flag values specified by the package author. Which as you say, is what you want. Just keep in mind that it need not correspond to any real configuration a user might even encounter, though it's probably the same or close most of the time.</p> <p>Simple right? :-)</p> <p>What we're doing, sort-of, is partially evaluating the package description using the available information. I'm going to change this API in future to make it more flexible and to make the partial evaluation notion more explicit. We'll be able to partially evaluate a generic package description using any partial set of information, OS, arch, ghc version (or range of versions), available packages (again, not necessarily all available package) etc and get back another generic package description. We've only finalised when we've resolved all the choices. As you're doing above we should also be able to do that using default flag values and not using any set of available packages.</p> Just to clarify…

When you call finalizePackageDescription you get to say something about flag values. You can specify true or false or you can not specify it at all. Then finalizePackageDescription will come up with true/false values for the flags that you did not specify. It does this based on the default values for the flags (given in the .cabal file by the package author) but more interestingly based on the possible flag values given the flag-conditional dependencies and the set of available packages. Now you’re not specifying any set of available packages (not the same as specifying none, then we could not finalise any package). So all constraints (that are not self-contradictory) will be presumed to be ok.

The result is that (since you use Nothing for the set of available packages) you’re getting the default flag values specified by the package author. Which as you say, is what you want. Just keep in mind that it need not correspond to any real configuration a user might even encounter, though it’s probably the same or close most of the time.

Simple right? :-)

What we’re doing, sort-of, is partially evaluating the package description using the available information. I’m going to change this API in future to make it more flexible and to make the partial evaluation notion more explicit. We’ll be able to partially evaluate a generic package description using any partial set of information, OS, arch, ghc version (or range of versions), available packages (again, not necessarily all available package) etc and get back another generic package description. We’ve only finalised when we’ve resolved all the choices. As you’re doing above we should also be able to do that using default flag values and not using any set of available packages.

]]> By: Magnus http://therning.org/magnus/archives/514/comment-page-1#comment-171363 Magnus Wed, 25 Feb 2009 16:29:15 +0000 http://therning.org/magnus/?p=514#comment-171363 <p>@Antoine, I believe I'd rather keep using <code>finalizePackageDescription</code> even for newer versions of Cabal. If I read it correctly <code>gPckgDeps</code> simply pulls out the <code>PackageDescription</code>, which AFAIU is at least similar to <code>flattenPackageDescription</code>. I really want to end up with the "default package description", which I believe is what I get when using <code>finalizePackageDescription</code> with an empty set of flags.</p> <p>@Duncan, actually I suppose I do care about flags, I want none to be set :-) AFAIU that will give me the "default package description", which is what I'm after.</p> @Antoine, I believe I’d rather keep using finalizePackageDescription even for newer versions of Cabal. If I read it correctly gPckgDeps simply pulls out the PackageDescription, which AFAIU is at least similar to flattenPackageDescription. I really want to end up with the “default package description”, which I believe is what I get when using finalizePackageDescription with an empty set of flags.

@Duncan, actually I suppose I do care about flags, I want none to be set :-) AFAIU that will give me the “default package description”, which is what I’m after.

]]> By: Duncan http://therning.org/magnus/archives/514/comment-page-1#comment-171361 Duncan Wed, 25 Feb 2009 15:32:47 +0000 http://therning.org/magnus/?p=514#comment-171361 <p>Note that if you do not care about flags etc then you can use the even simpler flattenPackageDescription. However, be aware that that will give you the union of all possible dependencies. This is not the same as the set of dependencies in any particular configuration. Indeed the union of all version constraints may be impossible.</p> <p>On the other hand finalisePackageDescription gives you the result for one particular configuration. So it does not reflect what the deps would be for another configuration if the .cabal file uses conditional dependencies.</p> <p>So which one is right to use depends on what it is you are trying to do.</p> Note that if you do not care about flags etc then you can use the even simpler flattenPackageDescription. However, be aware that that will give you the union of all possible dependencies. This is not the same as the set of dependencies in any particular configuration. Indeed the union of all version constraints may be impossible.

On the other hand finalisePackageDescription gives you the result for one particular configuration. So it does not reflect what the deps would be for another configuration if the .cabal file uses conditional dependencies.

So which one is right to use depends on what it is you are trying to do.

]]> By: Antoine Latter http://therning.org/magnus/archives/514/comment-page-1#comment-171326 Antoine Latter Wed, 25 Feb 2009 01:43:09 +0000 http://therning.org/magnus/?p=514#comment-171326 <p>For scraping deps from the newer parts of Cabal syntax, you can check out my attempt over <a href="http://panicsonic.blogspot.com/2009/02/dependencies-in-hackage-revisited.html" rel="nofollow">here</a>.</p> <p>You'll want to look at <code>gPckgDeps :: GenericPackageDescription -> [Dependency]</code>.</p> <p>It's a bit gruesome, I admit.</p> For scraping deps from the newer parts of Cabal syntax, you can check out my attempt over here.

You’ll want to look at gPckgDeps :: GenericPackageDescription -> [Dependency].

It’s a bit gruesome, I admit.

]]>