Document Paths_ related stuff

[phadej]

12:39  merijn phadej: You might still want some directory outside of the store inside ~/.cabal to keep runtime data caches/libexec stuff for "installed" executable
12:41  phadej isn't XdgCache what you want to use for caches?
12:42  merijn phadej: I was trying to see whether I could improve things in my phd thesis codebase, because right now I have a bunch of runnable python scripts inside the data dir since afaik there's no easy way to get them into any of those other directories
12:42  merijn phadej: tbh, I've never encountered a system where those XDG variables were set/used
12:43  phadej users are happy with defaults
12:44  merijn phadej: The default is "I now have 30 "hidden" directories in my home dir on linux", which tbh isn't great and I'd prefer not to contribute to that >.>
12:44  phadej merijn: yes, and no. I actually don't have ~/.cabal myself :)
12:44  phadej anymore
12:45  phadej but you can put ~/.cabal/config into ~/.config/cabal and set CABAL_CONFIG
12:45  phadej and put all other directories somewhere else
12:45  phadej problem with XDG is the word desktop, otherwise it's good
12:45  phadej expecially for caches
12:45  phadej as e.g. backup systems start to know that backuping ~/.cache doesn't make sense
12:45  merijn phadej: I know that ~/.cabal is configurable to be somewhere else, my point is: I'd like to piggyback on top of cabal for this (that's the entire point of having Paths_*, right?) but as of now it's rather unclear whether that's even feasible
12:46  phadej Ok, back to script
12:46  phadej I'm against using Cabal to distribute non-haskell stuff. If your library/executable is calling to the python script itself, then it's fine: scripts can be in dataDir
12:46  phadej but if you want to expose those scripts to the user directly: I just say no.
12:47  phadej We cannot cater for that.
12:47  phadej Python scripts are "easy" as they are system independent, but somewhere already asked about bundling system-dependent binary objects
12:47  phadej so just no.
12:48  merijn phadej: My scripts aren't user runnable, they're called by my haskell code to process some data
12:48  phadej well, then they are data, aren't they
12:48  phadej as in, it's irrelevant where they are
12:48  phadej if you want to organise them, cabal doesn't flatten the structure of data-files
12:49  phadej so you can put them in python-scripts/ e.g.
12:50  merijn phadej: Sure, I'm not saying "having them as data files in unacceptable", just saying that the current absence of documentation on the intended/supported usecase(s) of the various get*Dir makes it hard to decide if usage like that is appropriate
12:50  merijn phadej: For example, is data-files intended to only ever have read only data?
12:50  phadej well, you don't care about executable bit, do you?
12:51  merijn phadej: Or is it acceptable for my scripts to cache stuff in there too
12:51  phadej yes, that directory is read only
12:52  phadej or I mean, it problably isn't permission wise, but the location will change as soon your dependency changes
12:52  phadej (because of the hash)
12:52  phadej Use: http://hackage.haskell.org/package/directory-1.3.3.2/docs/System-Directory.html#v:getXdgDirectory
12:53  merijn phadej: Right, but it would help if this was written down somewhere (say, next to the section mentioning these paths) so that's also clear for people not as deep into cabal details :)
12:53  phadej merijn: well, i told you, you can now write that down ;)

[hvr]

btw, do we already have a ticket for the changes needed to the Paths_* functionality in order to address the long-standing problems introduced by the per-component mode?

[phadej]

@hvr, I remember only relocatable store related stuff.

[23Skidoo]

I found only #5543, which is somewhat related.

[arrowd]

I'm using cabal new-build to prepare packages of Haskell applications for FreeBSD. That means that the directory where cabal installs to and the directory where executable ends up on user system differs.

This is a problem for pandoc, because it tries to find its data files in cabal installation dir:

Could not find data file /wrkdirs/usr/ports/textproc/hs-pandoc/work/cabal-home/.cabal/share/x86_64-freebsd-ghc-8.6.3/pandoc-2.7.1/data/templates/default.man

I tried passing --datadir=/usr/local/share/pandoc to cabal new-build command, but the error stays. Is --datadir supposed to work with new-build machinery?

[hvr]

@arrowd see #4097 (comment) for a relevant related discussion

[arrowd]

@arrowd see #4097 (comment) for a relevant related discussion

I don't see how it is relevant. I don't want relocatable executable, I just want functions from Paths_* to have right prefix. Or at least getDataDirectory return whatever value --datadir have been supplied with.

[23Skidoo]

@arrowd Perhaps you can run pandoc via a script wrapper that sets the pandoc_datadir env var to the correct location?

[arrowd]

Thanks for the hint, but I don't need workarounds. In fact, I already found one - pandoc's embed_data_files option. However, I believe that new-build should respected flags like --data-dir, so no embedding or environment fiddling is required.

[arrowd]

@arrowd Perhaps you can run pandoc via a script wrapper that sets the pandoc_datadir env var to the correct location?

This workaround is also insufficient. For instance, when running haddock you need to set both haddock_datadir and haddock_api_datadir to make it work. So, theoretically, you have to set env vars for every dependency too.