search

dhall-lang / dhall-to-cabal

Compile Dhall expressions to Cabal files
MIT License
100 stars 19 forks source link

Add --output-dir and make it the default. #113

Closed quasicomputational closed 5 years ago

quasicomputational commented 6 years ago

Now it's easy to generate a .cabal file with the expected name, instead of having to manually insert the destination name into a command-line redirection. This is the 99% case, and the remaining 1% can use --output-stdout to pipe the generated file wherever they want.

quasicomputational commented 6 years ago

I am not entirely sure that I am using optparse-applicative the right way here. Ideally I'd be able to specify the default behaviour along with the flags and get documentation for free, but I couldn't see a better way to implement this.

Also, as noted, the regeneration message isn't perfect. I don't think we can do perfection here, especially in the presence of #114; I'm satisfied with giving the user a strong hint about what they should do and hoping they can figure out the rest if it's not quite right.

quasicomputational commented 6 years ago

Upon reflection, we also want to be able to have --output-dir work relative to the input file. I have a solution for this: a magic prefix component @ to get that behaviour. If we're running on foo/bar.dhall, --output-dir @/spam would be equivalent to --output-dir ./foo/spam, and --output-dir ./@ would go for the literal directory @.

quasicomputational commented 6 years ago

Note that I haven't actually been able to test --output-dir @ because of #114.

quasicomputational commented 6 years ago

I did manage to test this and it worked, but it definitely shouldn't land until the CWD stuff is cleared up, which isn't happening until dhall 1.16.

quasicomputational commented 6 years ago

RE regeneration instructions: I think it'd be sanest to give them relative to the Cabal file that the user is looking at, and to assume that it hasn't been moved about post-generation. Like I said I don't think we can do perfectly here, but I suspect that the 90% case is where users use our default flags and don't move the generated .cabal file about after we produce it.

ocharles commented 6 years ago

I find @ a little too magic. I'd rather we had --output-dir DIR and --output-relative DIR. Any reason not to do that? Though tbh, I'm not even convinced about --output-relative DIR and wonder if just --output-relative-to-input or something

quasicomputational commented 6 years ago

Fair enough on the magic. I thought I had a reason for not introducing an additional flag for it, but I can't remember the logic now and it evidently works.

The --help output is a bit hard to read but I think that's not really our fault; I'll file an optparse-applicative bug about it:

Usage: dhall-to-cabal ([<dhall input file>] [--explain] ([--output-dir-cwd DIR]
                      | [--output-dir-input DIR] | [--output-stdout]) |
                      [--print-type TYPE] [--self-contained] |
                      [--print-default TYPE] | [--version])
  Generate Cabal files from Dhall expressions

(alternatively, we could move to subcommands instead of modal switches, maybe...)

quasicomputational commented 5 years ago

This has been up for a while, I think it's useful functionality, and no-one seems to object to the new design, so I'll go ahead and merge.