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
[email protected] 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"
  }

[ezyang]

Is there any particular reason you want it to be a record, rather than just a series of top-level declarations?

[sophie-h]

Yes. It could be used as an argument to a function that generates a
--version or usage text. But that would require that the type
ProgramInfo is defined elsewhere.

[ezyang]

Right, and I think that is a price too far to pay (you could just pass the arguments individually.)

[dcoutts]

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 ;)

@qua-bla Ok, I think this is an artefact of the current sandbox impl, but not anything fundamental. The configuration for the paths is about where the program/lib will be installed to. This ought to be the same between different machines.

Think about it this way: for some arbitrary C project, you would not expect that:

./configure --prefix=/opt/this

vs

./configure --prefix=/opt/that

would produce identical binaries. Rather you would expect that to reproduce a build you should use the same install locations. Sure, it shouldn't matter what temp build dir you use, but where you configure the thing to end up does matter. This is the same thing that's going on with Cabal, the --prefix and install dirs.

You shouldn't be saying that to be reproducible programs must not use any data files or otherwise know where they live. That's perfectly ok and not a problem for reproducibility.

The problem you're seeing is that the current cabal sandbox mechansim defaults to setting the prefix to be inside the sandbox. That is the problem, not the Paths module.

That said, there are other good reasons to split and extend the generated modules. Split so the paths only has the paths, and extended so there's more generated info available. So I welcome that, but don't confuse it with reproducibility.

The other thing you may want to look at to improve reproducibility is to finish support for properly relocatable (aka prefix independent) packages. There's partial support for this already, but it needs pushing through to completion.

[qnikst]

I'll try to solve this issue

[domenkozar]

I'm a bit surprised that for statically (haskell wise) linked executables don't eliminate (via split sections) these bindings that are not used at all in the code.

[blackheaven]

Fixed by #8534

[wismill]

If fixed completely, can this issue be closed?

[andreabedini]

As fas as I can tell, #8534 implemented everything requested here. Feel free to reopen if you think otherwise.