Cabal: Explanation of named conditional sections?

[tfausak]

I'm confused by some of the fields on GenericPackageDescription. Take condExecutables for example. It's a list tuples of UnqualComponentNames and CondTrees. The first element of the tuple is a name of the section, which makes sense only if you ignore the fact that the Executables in the CondTree also have names (exeName).

The documentation doesn't say which of these is the "real" name, so I wrote a script to see what it looked like. This is with Cabal 2.0.0.2:

import Data.Bifunctor
import Distribution.PackageDescription
import Distribution.PackageDescription.Parse
import Distribution.Types.UnqualComponentName
main
  = print
  . bimap unUnqualComponentName unUnqualComponentName
  . fmap (exeName . condTreeData)
  . head
  . condExecutables
  . (\ (ParseOk _ x) -> x)
  . parseGenericPackageDescription
  $ "executable example"
-- ("example","")

I was surprised to see that the name inside the tree was empty! I expected them to have the same value.

Can someone explain why the data is structured this way? And would it be reasonable to set the names inside the tree to match the one on the outside? If not, why not?

[phadej]

In current master (i.e. using Parsec module) the names should be set.

[tfausak]

Indeed it is! I see the expected result with the current master branch (989676ef5501d1bb57db9e31f8ccaf9f0abe84af).

import Data.Bifunctor
import Data.ByteString.Char8 (pack)
import Distribution.PackageDescription
import Distribution.PackageDescription.Parsec
import Distribution.Types.UnqualComponentName
main
  = print
  . bimap unUnqualComponentName unUnqualComponentName
  . fmap (exeName . condTreeData)
  . head
  . condExecutables
  . (\ (w, e, m) -> maybe (error (show (w, e))) id m)
  . runParseResult
  . parseGenericPackageDescription
  . pack
  . unlines
  $ [
    "name: example",
    "version: 0",
    "executable example"
  ]
-- ("example","example")

Is it generally safe to use the master branch of Cabal?

[23Skidoo]

Is it generally safe to use the master branch of Cabal?

Safe in what sense? E.g. if you want your package to be installable with cabal-install 1.22, setting cabal-version to >= 2.1 will prevent you from achieving that goal.

[tfausak]

By "safe" I meant: Is master generally a release branch that's always buildable or a development branch where stuff comes and goes? I don't mind building against master and specifying Cabal ^>=2.1.0 as long as I can count on the interface being stable.

[phadej]

master is (at least should be) always buildable, but there aren't any stability guarantees.

[tfausak]

I'll take my chances, then. 😄

Bringing it back around to the original issue, is there any reason why the names exist in both places? Is one "more correct" than the other or something?

[23Skidoo]

As far as I can see, the names in condExecutables are initialised from exeNames and only used by cabal list, so they may actually be extraneous.

[23Skidoo]

So I think that they are there just so that you could get the component name without traversing the CondTree and should be always equal to the corresponding {exe,sublib,bench,..}Names.