Are there any examples on how to use <alias_mappin...
# general
Are there any examples on how to use alias_mapping with the tailor goal? Trying to see if we can configure
by default on our project BUILD files
I think it would be something like
{"python_library": "custom_python_library"}
But also, we should add this feature anyways. @proud-dentist-22844 recommended it too
yeah that would be a great feature to have for projects doing a soft rollout of lint checks.
Huh. I think I missed that alias_mapping feature in tailor. Probably because I didn't want to define macros for the most part, so that people can use the pants docs as much as possible to understand the BUILD files. The more custom macros/targets I add, the more I'll have to add custom documentation somewhere.
That said, it is pretty cool.
In the meantime to adding this feature to change defaults for fields, might ripgrep + sd be helpful? I think that may be what I do for helping my friend to adopt Pants
Also, what are you both thinking for how this API would look? I think something like this maybe?
Copy code
default_field_values = """
  "python_library": {
       "skip_mypy": True,
   "python_tests": {
       "skip_tests": True,
note that
./pants tailor
is generic to all languages, e.g. Shell. Ideally we have something flexible and don't hardcode the
fields as the only things you can change cc @happy-kitchen-89482
Use toml, not a triple quoted string.
Copy code
python_library = { skip_mypy = true }
python_tests = { skip_tests = true }
Or something like this
Copy code
skip_mypy = true
skip_pylint = false
field_defaults = { skip_tests = true }
lib/python/fizzbuzz = { skip_tests = false }
I tried to account for what gradually changing the defaults might look like. In one directory, where tests have already been enabled, I would want any new BUILD files under that directory to run tests, but new directories under other libs should stick with the default of disabling tests.
Use toml, not a triple quoted string.
We considered doing that when changing from
and it ended making it really difficult to (performantly) disambiguate between options vs subsystems. Might be easier to do now that we don't have subscopes like
though Dict options are really rare, so we went with it
overriding Pants's defaults overall is interesting, vs. only overriding what
./pants tailor
generates. I do have some concerns w/ it, like how your repo's defaults might diverge from
, which could be really confusing. But I see the appeal
All of my suggestions were under
, so I would only want to affect tailor (when you add this target to BUILD files, use these default settings to write the target into the BUILD file), not override the target defaults across the board.
👍 1
With the complexity involved in configuring tailor stuff, I think it would make sense to only allow customizing tailor from pants.toml, not on the command line.
hmm. You could even have a separate
file to help signal that “this is different”
Copy code
# Use this file to customize how ./pants tailor creates/updates BUILD files
# Keys are targets, values are a hash of keyword args to use when tailor adds that target to a BUILD file.
python_library = { skip_mypy = true }
python_tests = { skip_tests = true }

# This directory has already been migrated so that tests can run successfully.
# So, tailor will use these field values instead of the the field_defaults above
# for all BUILD files that are in the tree of directories under lib/python/fizzbuzz
python_tests = { skip_tests = false }