Add a Version_ module which does not depend on install dirs

[sophie-h]

I am using Paths_ (version) to output the version number in my project. However, the

bindir, libdir, datadir, libexecdir, sysconfdir :: FilePath

is making the binary non-reproducible. If this section can't be changed due to compatibility issues, there should be a new reproducible Buildconstants_ or what ever API.

By the way: It would be useful to export name and synopsis too, since they often appear in --version or --help.

[ezyang]

Well, we certainly can't delete it. What if we added a new Version_ module which contained the information you asked for?

[sophie-h]

That would be great and totally do the job.

[dcoutts]

is making the binary non-reproducible.

@qua-bla sorry if it's an obvious question, but why does that make it non-reproducible? Surely these install paths would be the same each time, if you're using the same configuration.

[sophie-h]

On Sat, Oct 1, 2016 at 2:26 AM, Duncan Coutts
notifications@github.com wrote:

Surely these install paths would be the same each time, if you're
using the same configuration.

Sure, but why should the config be the same? I don't want force the
build server to do stuff outside the sandbox.

The idea of reproducible builds is not that I can build it twice on
/my/ computer ;)

[ezyang]

I think we'd be happy to take a PR on this. But before working on it, it would be worth to write the putative docs; i.e., what would the API of this module be.

[sophie-h]

It would be also possible to fix this via a CPP #ifdef in Paths_ that can be controlled via a cabal option (something like "enable-reproducibility"). The advantage would be that package maintainers can fix reproducibility issues without touching code and no new API would be introduced.

On the other hand the name Paths_ is odd anyways and replacing Paths_ with Version_ as a package maintainer is doable.

Any thoughts?

[ezyang]

I'm aesthetically opposed to putting CPP in Paths but I don't have any technical reasons for it (besides, I guess, CPP is bad).

[hvr]

but if we had a Paths_ w/o installdirs, then how would a package find where cabal installed its package data and other stuff?

[ezyang]

Well, the point is anyone who would disable the install paths bits wouldn't actually use it (it can't be disabled by default.)

[hvr]

maybe we should have a new field/setting in .cabal to declare whether a package needs any paths, as then we could automatically leave them off for all packages inside an install-plan which don't need them.

[sophie-h]

I'm aesthetically opposed to putting CPP in Paths

totally

but I don't have any technical reasons for it (besides, I guess, CPP is bad).

There would be a new config options or something that would have to be carried around for ever. Sound like higher support cost to me. Also changing the flags in my small test implementation required a strange build-clean-build sequence to get the "actual" reproducible result. (There will be a good reason, but who wants to deal with that.)

How about

module ProgramInfo_test
  ( ProgramInfo
  , programInfo
  , programName
  , programSynopsis
  , programVersion
  , programCopyright
  , programHomepage
  ) where

import Data.Version (Version, makeVersion)

data ProgramInfo = ProgramInfo
  { programName :: String
  , programVersion :: Version
  , programSynopsis :: String
  , programCopyright :: String
  , programHomepage :: String
  }

programInfo :: ProgramInfo
programInfo =
  ProgramInfo
  { programName = "test"
  , programVersion = makeVersion [0, 1, 0, 0]
  , programSynopsis = "Example project"
  , programCopyright = "(c) 2016 Me"
  , programHomepage = "https://example.org"
  }