Hi, could I please get some eyes on this email to pants-devel titled:

Migrating from pants.ini to pants.toml (Optional)

? https://docs.google.com/document/d/1WR2fb0CecquGr0KJbvnZXE1fZXbA5xhGmzai8wDcpRw/edit

Reviewed and looks good to me. One minor suggestion. Note: I didn’t test the steps to migrating from ini to toml, so I’m trusting you did test it 🙂

Thank you!

so I’m trusting you did test it 🙂

Yes, with both Pants and Toolchain. The most vague step is on fixing things manually, but it’s hard to prescribe the exact solutions because there are a couple permutations. My hope is that the email + the docs we just updated + editor validation and

./pants

error messages + the TOML spec + the 80% auto-generated changes from the script will be enough for people to see how to fix the remaining issues. (As DMed), I keep going back and forth on trying to prescribe a solution for every possible issue but whenever I try to write this it gets very verbose and confusing. So, I think we rely on the above hints

one solution i was considering to enable switching to toml without breaking

pants.ini

file paths that may be hardcoded in a million other places is to make the config parsing code symlink-aware, and select which config file format to use depending on the symlink target's extension, instead of the symlink source. this would allow migrating

pants.ini

to

pants.toml

, then symlinking

pants.ini

to

pants.toml

, and having pants correctly use the TOML parser, even if provided

pants.ini

as a file path. since we would like to deprecate

pants.ini

, i think i'm comfortable with the mild dissonance. do you have any thoughts on that?

Personally, that makes me a bit uncomfortable. It sounds like adding more cognitive overhead to future us instead of investing the time into “doing the right thing” and changing these links. It’s only my opinion, though. Would be interested in hearing more opinions.

Thanks for the proposal! I think I bias towards Pierre’s thoughts on this to keep Pants simpler if possible It could be worth auditing how much of a problem this is for other users too, where they hardcode pants.ini. For example, Toolchain doesn’t have any reference like this. Stu recently commented that it’s preferred to use

./pants options

rather than explicitly reading the config file. I know Twitter has a lot of places that refer to pants.ini, but I’m not sure if that’s a problem for other users too

Another approach that wouldn’t take symlinks to do would be to have the config loading code check for both the pants ini and toml files, looking for the provided one first, and warning with the external callsite if the requested one wasn’t the one that was found. Adding that mechanism would do double duty because if we deprecate pants.ini, it’s precisely the best spot to add a warning about it.

instead of investing the time into “doing the right thing” and changing these links.

if it's possible for us to change the links internally, then, we should probably be looking to decide on a

deprecation_start_date

to agree on, and we should maybe bring this up with

pants-devel

so we can make sure other users don't get surprised.