https://pantsbuild.org/ logo
#general
Title
# general
h

hundreds-father-404

03/04/2020, 2:18 PM
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
👍 1
f

fancy-motherboard-24956

03/04/2020, 2:27 PM
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 🙂
❤️ 1
h

hundreds-father-404

03/04/2020, 2:34 PM
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
a

aloof-angle-91616

03/04/2020, 2:48 PM
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?
f

fancy-motherboard-24956

03/04/2020, 2:51 PM
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.
👍 1
h

hundreds-father-404

03/04/2020, 3:00 PM
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
I would really like to deprecate pants.ini if possible, so I appreciate you thinking of ways to make that feasible :) Deprecating will make the code simpler, eg possibly no longer stringifying every value and maybe even exploring more advanced string interpolation. But, it’s fine with me to give users more time
f

fancy-queen-20734

03/04/2020, 6:49 PM
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.
a

aloof-angle-91616

03/05/2020, 6:03 PM
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.
1
💯 1
i was under the impression we were saying that it was infeasible for twitter to change those strings anytime soon
i would hope that's not the case though obviously
also would like to second @fancy-queen-20734:
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.
just all of this
2 Views