ancient-vegetable-1055610/21/2021, 5:38 PM
file that I can’t replicate on my M1 (pwith py3.9) or on a linux box (with py3.7). There’s no real error in the CI output other than what the file is. How can I diagnose this?
witty-crayon-2278610/21/2021, 5:40 PM
goal, apparently cc @hundreds-father-404
ancient-vegetable-1055610/21/2021, 5:41 PM
hundreds-father-40410/21/2021, 5:49 PM
I can update the output to say "Run
to fix these issues"?
ancient-vegetable-1055610/21/2021, 5:49 PM
hundreds-father-40410/21/2021, 5:50 PM
ancient-vegetable-1055610/21/2021, 5:52 PM
hundreds-father-40410/21/2021, 5:54 PM
without major breaking changes. It violates a bunch of very core assumptions like how running
returns all targets who are defined there
./pants list path/to/BUILD
ancient-vegetable-1055610/21/2021, 5:55 PM
witty-crayon-2278610/21/2021, 6:04 PM
might eventually allow us to adjust those semantics. i don’t expect much of a slippery slope there.
hundreds-father-40410/21/2021, 6:29 PM
does not handle the Specs code that translates
into all targets defined there, that is done beforehand.
can't hack that code
witty-crayon-2278610/21/2021, 6:30 PM
in the release notes to fix deprecations)
hundreds-father-40410/21/2021, 6:35 PM
tailor doesBy doing a bunch of weird special casing of
and ignoring our
handling of things like
. NB that
errors It's probably possible to put intense special casing into
./pants --changed-since=HEAD tailor
, but it would be very involved and would mean that those goals behave differently than
the “update-build-files” goal started as a way to remove deprecated names/code,My mental model for the goal is:
Make Pants config files be in tip-top shape.Where there's a difference between your own code vs. Pants config files like BUILD and pants.toml
witty-crayon-2278610/21/2021, 6:37 PM
, and so probably better in a separate goal like
hundreds-father-40410/21/2021, 6:38 PM
but i don’t think that this is time critical for 2.8.xAgreed, I don't have the time to try to hack Black on BUILD files into
. I tried doing that last month and it was going to be much too hard Doing it via
was an easy win for a feature users have been asking about for months. If folks feel strongly that it shouldn't live in
, I can revert that PR? But won't have time to do it with
and in that regard, removing deprecations is very much like pyupgrade… sortof odd to go directly in fmt , and so probably better in a separate goal like mend or fixKey difference is pyupgrade runs on your own code, not Pants config files
witty-crayon-2278610/21/2021, 6:39 PM
Doing it viathis might be good, but i don’t feel strongly about it? while removing deprecations, folks will end up reformatting all their BUILD files as well. usually that would be two commits, in order to be a bit easier to reviewwas an easy win for a feature users have been asking about for months. If folks feel strongly that it shouldn’t live in
update-build-files, I can revert that PR? But won’t have time to do it with
hundreds-father-40410/21/2021, 6:42 PM
while removing deprecations, folks will end up reformatting all their BUILD files as well. usually that would be two commits, in order to be a bit easier to reviewIf there are BUILD files that weren't already formatted, yep. Which is why we'll recommend setting
the first time. (In fact, I can update our deprecation message to say that!) But it was 10 vs 2 votes that
should be enabled by default, so went with that. Once your repo is already formatted, then bumping to a new Pants version and running
should mean that you are only fixing deprecations because Black no-ops. This is only a first-time adoption quirk
but i don’t feel strongly about itI really want to have Pants support running Black on BUILD files, particularly because the
field has so much nesting and I hate manually spending time fixing that formatting Trying to be pragmatic about how we can get that win in the face of a lot of time/priority constraints
witty-crayon-2278610/21/2021, 6:45 PM
is an odd goal out right now, because it overlaps semantically with other goals. it exposes an implementation detail that it is a separate goal
hundreds-father-40410/21/2021, 6:50 PM
) to update
by removing safe deprecations. Same with not wanting those goals to add missing target definitions That is, that there's value in separating operating on user code vs. Pants config Maybe we should bring that question to #general?
witty-crayon-2278610/21/2021, 6:52 PM
say… i would expect that based on the name, but perhaps that’s because i’m familiar with
to. but i’m definitely not suggesting that deprecation removal should be there (for the same reason i’m sketched out by
being there: putting that in a dedicated goal would be much more comfortable)
hundreds-father-40410/21/2021, 6:54 PM
witty-crayon-2278610/21/2021, 6:54 PM
to do that though?
, but something called
all have “fix” tools (from go’s ancestry, i think)
hundreds-father-40410/21/2021, 7:00 PM
) • fix safe deprecations, like renaming target types • format BUILD files with Black • plugin hook for you to automate your own changes to BUILD files Option A: a goal like
does those 4 things, only on Pants's config.
, and maybe
are only for your own code Option B: a new
goal will add missing target definitions and fix safe deprecations, in addition to running tools like Pyupgrade and Autoflake on your own code.
will run Black on both your own code and BUILD files Comments welcomed too!
witty-crayon-2278610/21/2021, 7:04 PM
Option A: a goal like “`update-pants-config`” which does those 3 things, only on Pants’ config.,
fmt, and maybe
lintare only for your own code
to also operate on BUILD files?
hundreds-father-40410/21/2021, 7:07 PM
changes my answer. I think it probably does make sense that
into `fmt`/`lint`/`fix` is not super realistic for Pants 2.8, including because it requires Specs changes How do you feel about landing as is, with the vision that we fix this all to unify?
goal before we stabilize Pants 2.8 and Pyupgrade + Autoflake using
witty-crayon-2278610/21/2021, 7:11 PM
as for being used for anything other than the upgrade, we’re fine for 2.8.x
hundreds-father-40410/21/2021, 7:14 PM
witty-crayon-2278610/21/2021, 7:15 PM
hundreds-father-40410/21/2021, 7:17 PM
. And it ensures your BUILD files are formatted
in addition to `fmt`/`lint`! But that doesn't mean there's no utility, only that it's clunky
./pants update-build-files --check
witty-crayon-2278610/21/2021, 7:19 PM
does BUILD files as well, people would be undoing those CI config edits.
hundreds-father-40410/21/2021, 7:22 PM
people would be undoing those CI config edits.Sure, but that's not A Huge Deal imo. I agree it would have been much better if we could have done this via
right away, but we couldn't. So, in the meantime, recommend users do the useful thing even if it's a bit clunky and that clunkiness will soon* go away *Not sure on soon. Merging `validate`/`update-build-files`/`tailor` into `fmt`/`fix` is going to require lots of changes and very likely it wouldn't make it into 2.9