An option to set the location of config files.
Review Request #3500 - Created Feb. 25, 2016 and submitted
|kwlzn, mateor, patricklaw, stuhood|
This option is special-cased, to work around the obvious chicken-and-egg problem. Why is this useful? A few reasons. - Previously the default pants.ini location was automagically used in several different possible control paths, which was potentially surprising to people trying to override it. - It allows us to generate reference documentation without applying our pants.ini-based defaults, by setting the flag to an empty list. - It allows us to remove the configpaths= constructor argument to OptionsBootstrapper, which was only used in tests anyway. - In the future it will allow us to deprecate --config-override, and possibly the pantsrc-related options, and consolidate everything into the single --pants-config-files option. ignore values from config and env vars when generating reference docs.
CI passes: https://travis-ci.org/pantsbuild/pants/builds/112340670
If this is the case, I'm not very excited about the prospect of removing support for pantsrc_files. We have some of these set in pants.ini and developers aren't going to want to set them on the command line every time.
pantsrc_files: [ "squarepants/pants-jvm-platform-gen.ini", # For local developer settings. Not checked into git "pants-local.ini", ]
If we put the item in our
./pantswrapper, this logic will only process the first instance of --pants-config-files, meaning to get everything to work, they'll have to re-specify these options to add any new items to --pants-config-files.
any reason to not just
didn't see any other uses of
Config.empty()and seems simple enough to just inline for readability.
IIUC, wouldn't this mean that in order to logically append to the default config, that a user would have to know and provide the path to the default
we have a few cases where we rely on
--config-overrideto overlay sets of bundled changes on top of our default config. e.g.:
I think for these sorts of cases, the existing form of
--config-overrideprovides a far superior user experience than having to do this to achieve the same thing:
could we find a way to reconcile the idea of clobbering the config file sequence vs simply appending to it? seems like there are use cases for both.
Addressed code review comments.
Revision 3 (+163 -49)