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

little-zoo-57121

09/27/2022, 3:36 PM
Hello all 👋 we're using the rc version of pants 2.14 (for the docker tags plugin capabilities), and it seems
pants filter
may be broken? When using filter values that worked in 2.12 or trying anything different we just get the following cryptic error. The only value that does not result in this is
--help
1
c

curved-television-6568

09/27/2022, 3:39 PM
Hi Steve, The
filter
goal was deprecated in 2.13, and removed in 2.14:
User API Changes
• Deprecate
filter
goal now that
filter
options can be used from any goal (#15600)
https://github.com/pantsbuild/pants/blob/main/src/python/pants/notes/2.13.x.md https://github.com/pantsbuild/pants/pull/15600
The filter arguments work directly on the other goals in 2.13 and up.
If you try out
./pants filter
on 2.13 you will get a deprecation message explaining how to adapt 😉 (or just read the changes in the linked PR)
l

little-zoo-57121

09/27/2022, 3:43 PM
ah ok! we skipped 2.13 as we had a hacky plugin that worked for 2.12 and just jumped directly to 2.14. Thanks so much, we'll read up on the differences
👍 1
b

bitter-ability-32190

09/27/2022, 3:52 PM
FWIW we recommend sequentially upgrading, even if you're going to skip a version, because of these kinds of things. So bump to 2.13, splash around a while,then bump again
l

little-zoo-57121

09/27/2022, 3:53 PM
We tried, unfortunately our hacked plugin broke in too many places. We could not resolve it without 2.14
b

bitter-ability-32190

09/27/2022, 3:57 PM
Ah yeah, plugins. Such a double-edged sword. Feel free to upstream if it makes sense, makes for less maintenance 😛
☝️ 1
h

hundreds-father-404

09/27/2022, 5:40 PM
@witty-crayon-22786 or @bitter-ability-32190 thoughts on us adding this goal back until at least 2.17, per @flat-zoo-31952’s proposals for a stronger deprecation policy?
w

witty-crayon-22786

09/27/2022, 5:41 PM
a middle ground might just be adding back a tombstone of sorts, that tells you where it went.
i don’t think fully re-adding it would make sense.
b

bitter-ability-32190

09/27/2022, 5:41 PM
+1 to Stu's
h

hundreds-father-404

09/27/2022, 5:42 PM
Ah I like that, something like the goal, but it returns exit code 1. and teach
help
to ignore it
💯 1
Oh you weren't kidding it's a cryptic error. Oof. Compare this:
Copy code
❯ ./pants black
Unknown goal: black
Use `./pants help` to get help.
Use `./pants help goals` to list goals.
Copy code
❯ ./pants filter
12:44:15.72 [ERROR] 'filter'
f

flat-zoo-31952

09/27/2022, 5:47 PM
There’s nothing good that comes of removing filter. I’d argue to add it back
h

hundreds-father-404

09/27/2022, 5:48 PM
There’s nothing good that comes of removing filter.
Yeah, it's true. Other than maybe cluttering
./pants help goals
, which we could filter this out if we want
it's very little code for us to keep
filter
forever
f

flat-zoo-31952

09/27/2022, 5:50 PM
Yeah the deprecation policy I’m working on recommends that deprecated items be removed from things like default help but kept forever otherwise
👍 1
b

bitter-ability-32190

09/27/2022, 5:51 PM
I think that leaves the debate for "tombstone or code" open
h

hundreds-father-404

09/27/2022, 5:52 PM
It's friendlier to let
filter
keep working forever imo. Why force users to change already working scripts? It's literally like 20 lines of code for us to do that
b

bitter-ability-32190

09/27/2022, 5:53 PM
I meant in general.
filter
may be 20 lines, but not all goals that travel this path will be
w

witty-crayon-22786

09/27/2022, 5:53 PM
It’s friendlier to let
filter
keep working forever imo. Why force users to change already working scripts? It’s literally like 20 lines of code for us to do that
because it’s not always so easy to maintain things like that. the policy needs to allow for some flexibility, because in some cases the burden of backwards compatibility is much higher.
coke 1
c

curved-television-6568

09/27/2022, 5:53 PM
Agreed. It’ll be a trade-off between compatibility and maintenance burden
w

witty-crayon-22786

09/27/2022, 5:53 PM
coke s all around 😃
coke 1
f

flat-zoo-31952

09/27/2022, 5:54 PM
Why a tombstone? What good does that do? Its only nice by comparison with depreciation with no breadcrumbs
b

bitter-ability-32190

09/27/2022, 5:54 PM
Support and maintenance, primarily
f

flat-zoo-31952

09/27/2022, 5:55 PM
I’m a bit weary of the “maintenance burden” argument. Most of these could be represented as simple aliases or mappings. If it’s legit complicated then maybe there’s a point. But it rarely is
👍 1
w

witty-crayon-22786

09/27/2022, 5:57 PM
it’s a spectrum… i think our point is just that it needs to be modeled in the deprecation policy as a spectrum, rather than in terms of absolutes. take a look at the way the Java ecosystem froze for a few decades… then look at how hard they went in the opposite direction (too hard, perhaps…). 100% back compat is too much… 0% back compat is too little, etc.
😒 1
👍 2
b

bitter-ability-32190

09/27/2022, 6:01 PM
You could argue removal from a language as multi-version-compatible as Python is prohibitively expensive, as people don't control what version(s) their dependencies were tested against/support. Yet deprecation->removal exists there as well.
f

flat-zoo-31952

09/27/2022, 6:02 PM
I think that’s a bit inappropriate a comparison for this case. There’s a clear mapping to the existing feature. Users need API evolution as well as stability. There’s really no trade off here.
b

bitter-ability-32190

09/27/2022, 6:02 PM
(Still talking i_n general_)
f

flat-zoo-31952

09/27/2022, 6:03 PM
Of course we will have to break things at some point but the bend-don’t-break argument gets abused here too mean “break often” IMO. There’s no real user centric justification for it
w

witty-crayon-22786

09/27/2022, 6:05 PM
tech debt is a thing. the cost of the debt obviously varies, and
filter
is clearly closer to one end of the spectrum.
1
h

hundreds-father-404

09/27/2022, 6:08 PM
Yeah, I like the spectrum idea. Imo, we (especially me) were on the extreme end of "there's a better way now, so remove the old way!"
filter
was a good example of that, it was deprecated (by me) from a purity perspective imo, which isn't compelling enough, given how it's 40 lines of code to support
👍🏻 1
c

curved-television-6568

09/27/2022, 6:37 PM
I like the way they’ve addressed this in the Pike programming language (from a user perspective at least), with the
#pike
directive: https://pike.lysator.liu.se/docs/man/chapter_5.html#5.4
f

flat-zoo-31952

09/28/2022, 1:10 PM
I'm not sure that's practical for our case, and it also sounds like it would be a nightmare to support. But maybe they have a neat way to deal with that in their codebase
2
c

curved-television-6568

09/28/2022, 1:15 PM
Yeah, sorry, brought it up as a fun fact, not as a feasible approach in our case. Could’ve stated that 😉
l

little-zoo-57121

09/28/2022, 1:19 PM
Even though it was actually just something we missed by jumping a version I just wanted to add my 2 cents here. Personally, I'm a fan of the removal of filter and the addition of the logic to the other goals. I find the piping logic to be a bit more clear now, as the underlying principles can be confusing (direct here, xargs there, etc) and this seems to make it easier to deal with.
f

flat-zoo-31952

09/28/2022, 1:29 PM
Yeah I like that you can add filter to other goals. I think this is a great thing. But you shouldn't have to come to Slack to find that out. IMO
./pants filter
should work in perpetuity with a deprecation warning. There's all kinds of reasons we want to keep it working for users into the future. One is that changing it imposes a cost on existing Pants "administrators" just for updating. It potentially breaks muscle memory for more causal users. And for newer users it makes it so the following things don't really work, which can lead to frustration or abandonment if they aren't able to solve their problems: • Commands gleaned from older blog posts • Techniques discovered from earlier aborted attempts at integration • Suggestions from other users who may not be as up-to-date in their usage patterns
👍 2
h

hundreds-father-404

09/28/2022, 2:36 PM
should work in perpetuity with a deprecation warning.
Hm, yeah, I should add this to my PR restoring `filter`; we do want to encourage people to use the better approach
l

little-zoo-57121

09/28/2022, 3:23 PM
since we're kind of discussing api changes, I wanted to ask a bit about
tailor
now requiring targets in 2.14? I'm wondering about this as it's kind of supposed to be the thing telling me about the targets in my repo it found
f

flat-zoo-31952

09/28/2022, 3:46 PM
./pants tailor '**'
is the command that will best approximate the old behavio that I've found
l

little-zoo-57121

09/28/2022, 3:51 PM
yeah just seems a bit odd to me personally. now when adding pants to an existing/new project
./pants tailor
won't actually get you set up as before. Now you need to add args to the command for the thing that is supposed to put the build files in the project and/or check the build files. I've just always seen it as the goal that was telling me about the targets it found, but now I have to add to the invocation when I add say a new folder in my source
w

witty-crayon-22786

09/28/2022, 4:00 PM
./pants tailor ::
should always be equivalent to
./pants tailor
from before, but yea: sorry for the trouble there.
that’s a more tech-debty example: @hundreds-father-404 made the CLI semantics much more consistent across use cases, and so it should improve usability in a lot of common cases. but needing to maintain different specs semantics for different goals (or deprecated versions of the same) would make it more challenging to improve things moving forward.
f

flat-zoo-31952

09/28/2022, 4:04 PM
I think the motivation was to bring it in line with other goals and simplify argument handling. Conceptually it makes a lot of sense, but it’s also a disruptive change that’s more confusing than I think many members of the pants team realize
w

witty-crayon-22786

09/28/2022, 4:04 PM
yea
h

hundreds-father-404

09/28/2022, 4:40 PM
These improvements are thanks to this specific
tailor
change: • you can now say to run on only some things, like
./pants tailor project:: -project/but_not_me
• you can now use
./pants --changed-since=HEAD
tailor And now, indeed, all goals behave the same way for CLI arguments, whereas before some were weird and special-cased like
tailor
f

flat-zoo-31952

09/28/2022, 5:09 PM
I agree the new way is more consistent, but I’d argue that for future changes like this (changes to argument semantics) we should use a new goal and preserve the old goal with its old semantics as a deprecated alias of the new goal with a minimal translation layer to ensure the old semantics work with the new implementation
h

hundreds-father-404

09/28/2022, 5:20 PM
I'd be open to something like that. Challenge is we need to come up with a new name, as the old name is squatted on
f

flat-zoo-31952

09/28/2022, 5:29 PM
Yeah it’s not free but I think it’s a better way forward. I think the ship has sailed with tailor 🚢 👖 ✂️ but for the future I’m trying to include this n the deprecation policy updates
c

curved-television-6568

09/28/2022, 5:35 PM
tailor2
,
tailor3
… ? 😛 (as examples)
🙈 1
🙉 1
😅 1