file.Write doesn't respect outputDir

[hojerst]

Currently file.Write doesn't respect the outputDir set via config or command line. As it is also not possible to access the set outputDir via a well known var/context var, the only workaround is passing another context var with the outputDir manually and construct output paths manually. However, this falls apart as soon as the outputDir is set outside of the current working directory because of its security check.

IMHO the "working directory" in context of file.Write should be the outputDir set and not the current directory.

[hairyhenderson]

Sorry for the delay...

Limiting file.Write to the current working directory (and subdirectories) was a deliberate choice for security purposes, but I do see (after digging way back) that I did originally consider allowing setting the current working directory as a command line option: #485 (comment)

To be honest, this still doesn't seem required to me, as it's quite straightforward to just cd to the right location before running gomplate.

Changing the behaviour to use the outputDir (if it's even set!) would cause significant breakages with existing uses so I'm not keen on that at all.

[hojerst]

well you are right about being able to cd to the target regarding the output dir, however all included templates / configs are also relative to the current working directory.

in my usecase i want to store a config and multiple templates in a git repo and generate templates in another output folder somewhere outside of the git repo. (i.e. all paths in the config should be relative so the git repo can be checked out anywhere and generation just works). if i cd into the output first, the config needs to have abolute paths; if i run everthing from the template directory the generation fails because of the "not in workdir rule".

in my opinion the rule to allow file generation below the output folder only makes more sense as the current one, because when i specify an output folder, i don't really expect something to even be able to generate in my current working directory or somwhere outside of the output directory. maybe thats just me, though.

[hairyhenderson]

Thanks for the feedback @hojerst - I think I understand...

Here's a question - when you use file.Write, are you also rendering regular templates into the outputDir? Or are you just expecting outputDir to affect file.Write's working directory?

[hojerst]

currently i'm actually doing both (normal templates and dynamic files with Files.Write). I'm happy with some refactoring though.

I basically use gomplate as a docs generator: I parse a source repo with an analyzer to generate a yaml file with descriptions of code in a structured format. this single yaml file is then passed to gomplate to generate different kinds of output formats. for example an bunch of markdown files for a hugo based website or a single markdown README. (output format is based on the inputDir/config file, while the input yaml is the same regardless of output format).

so to clarify: in a single run currently have formats which generate just a bunch of dynamic files based on dynamic inputs. and some are with a wellknown output file(s) with dynamic contents. sometimes both at the same time (like a index file which is always named the same and some dynamic files based on inputs)

[hairyhenderson]

Ah, thanks for the explanation. I do a similar thing for gomplate's docs, though without using file.Write.

How about using a commandline flag or environment variable to change the behaviour? Would that work for you? That way we could avoid breaking existing use-cases while still allowing this use-case for you. I'm not sure what a good flag name would be though...

[github-actions]

This issue is stale because it has been open for 60 days with no
activity. If it is no longer relevant or necessary, please close it.
Given no action, it will be closed in 14 days.

If it's still relevant, one of the following will remove the stale
marking:

• A maintainer can add this issue to a milestone to indicate that
  it's been accepted and will be worked on
• A maintainer can remove the stale label
• Anyone can post an update or other comment

[hojerst]

Sorry, missed your answer completely. Yeah, a cli flag / env var would be fine for me.

--dynamic-files-in-outputdir ? or something like that?

[github-actions]

This issue is stale because it has been open for 60 days with no
activity. If it is no longer relevant or necessary, please close it.
Given no action, it will be closed in 14 days.

If it's still relevant, one of the following will remove the stale
marking:

• A maintainer can add this issue to a milestone to indicate that
  it's been accepted and will be worked on
• A maintainer can remove the stale label
• Anyone can post an update or other comment