Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature request: read fpmrc from a custom path #1902

Closed
hjpotter92 opened this issue May 16, 2022 · 9 comments
Closed

feature request: read fpmrc from a custom path #1902

hjpotter92 opened this issue May 16, 2022 · 9 comments

Comments

@hjpotter92
Copy link

Currently, the location of .fpm rc files are hardcoded to $CWD/.fpm and $HOME/.fpm. For some of my CI pipelines, the file is actually mounted to /var/secrets/<random-name> by the builder.

This leads to having to add a new step which copies over the secrets to local-dir before fpm can be launched.

Please add a custom command-line flag such that this path can be provided manually, something like:

fpm --config-file /var/secrets/10f51d93-b39a-4e0c-aa9f-f6393b03bcf1

# OR
fpm --fpmrc-file /var/secrets/10f51d93-b39a-4e0c-aa9f-f6393b03bcf1
@jordansissel
Copy link
Owner

I like the idea. A similar idea was proposed in #1172, so you're not alone in wanting this :)

I haven't thought about this in a while, but it should be doable. There's some implementation complexity like how to report circular references, for example an fpmrc that includes itself.

@jordansissel
Copy link
Owner

Should the fpmrc flag processes the flags immediately or afterwards? Example, if --fpmrc myflags is given and that file contains --version 2.0, then what is the "version" value after fpm --fpmrc myflags --version 1.0 ? Is it 1.0 or 2.0?

@jordansissel
Copy link
Owner

I did some exploration to see how hard this might be to implement, and I'm not sure it could be easily done with a flag. The reason is that fpm uses a library called Clamp to do command-line argument processing, and Clamp doesn't seem to support something like this.

Basically, I was looking for something in Clamp that would let me, during option/argument processing, to add more options to process. I couldn't find any. The code that might let me is pretty deep within Clamp and doesn't expose the methods to even let me try it.

The current .fpm file support is kind of hacky but works because it modifies the command line flags before we begin processing them:

fpm/lib/fpm/command.rb

Lines 524 to 578 in 7881705

def run(run_args)
logger.subscribe(STDOUT)
# Short circuit for a `fpm --version` or `fpm -v` short invocation that
# is the user asking us for the version of fpm.
if run_args == [ "-v" ] || run_args == [ "--version" ]
puts FPM::VERSION
return 0
end
# fpm initialization files, note the order of the following array is
# important, try .fpm in users home directory first and then the current
# directory
rc_files = [ ".fpm" ]
rc_files << File.join(ENV["HOME"], ".fpm") if ENV["HOME"]
rc_args = []
if ENV["FPMOPTS"]
logger.warn("Loading flags from FPMOPTS environment variable")
rc_args.push(*Shellwords.shellsplit(ENV["FPMOPTS"]))
end
rc_files.each do |rc_file|
if File.readable? rc_file
logger.warn("Loading flags from rc file #{rc_file}")
rc_args.push(*Shellwords.shellsplit(File.read(rc_file)))
end
end
flags = []
args = []
while rc_args.size > 0 do
arg = rc_args.shift
opt = self.class.find_option(arg)
if opt and not opt.flag?
flags.push(arg)
flags.push(rc_args.shift)
elsif opt or arg[0] == "-"
flags.push(arg)
else
args.push(arg)
end
end
logger.warn("Additional options: #{flags.join " "}") if flags.size > 0
logger.warn("Additional arguments: #{args.join " "}") if args.size > 0
ARGV.unshift(*flags)
ARGV.push(*args)
super(run_args)
rescue FPM::Package::InvalidArgument => e
logger.error("Invalid package argument: #{e}")
return 1
end # def run

Basically, when you run fpm, it checks:

We have a kind of chicken and egg problem that only Clamp really knows how to process fpm's command line flag, and fpm doesn't have the kind of control that would allow --fpmrc some/path to load arbitrary command line arguments the same way that $PWD/.fpm does.

I'm still trying to think of a way to add this feature as a command line flag...

@hjpotter92
Copy link
Author

Should the fpmrc flag processes the flags immediately or afterwards? Example, if --fpmrc myflags is given and that file contains --version 2.0, then what is the "version" value after fpm --fpmrc myflags --version 1.0 ? Is it 1.0 or 2.0?

inline arguments should always have a higher priority. the order that i've generally seen in practice has been:

  1. env. vars
  2. config file(s)
    • /etc/config (system-global)
    • $HOME/config (user-global)
    • $PWD/config (project-scope/dir-scope)
    • --config (inline)
  3. explicit argument

@jordansissel
Copy link
Owner

I have one solution that might work. FPM supports an environment variable "FPMOPTS" where it will use the contents of this variable as flags.

#1827

% FPMOPTS="--version 1.0" fpm -s empty -t rpm -n example
Loading flags from FPMOPTS environment variable {:level=>:warn}
Additional options: --version 1.0 {:level=>:warn}
Created package {:path=>"example-1.0-1.noarch.rpm"}

In #1827 I proposed maybe using a file for your config and using cat to put the contents of this file into FPMOPTS, like:

export FPMOPTS="$(cat /path/to/fpm.config)"
fpm -s dir -t rpm /my/files

@jordansissel
Copy link
Owner

Noting for future: I may have found a way to do this with a flag.
https://github.com/mdub/clamp/blob/03f1e6585438aadeb0e0df48e6512c87b05e79b2/lib/clamp/option/parsing.rb#L50-L52

I made a small demo to see if the idea works, and I think it'll work!
https://gist.github.com/jordansissel/557bc77f58a478cbfa7d072ca94be854

I don't know when it'll be implemented in fpm, but at least I feel like it's possible to have a flag like --fpmrc path/to/fpmflags :)

@jordansissel
Copy link
Owner

Draft in progress! #1905

@jordansissel
Copy link
Owner

Fixed, I hope, by #1905 which adds --fpm-options-file flag

@jordansissel
Copy link
Owner

fpm 1.15.0 released with this new --fpm-options-file flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants