https://pantsbuild.org/ logo
Join Slack
Powered by
Hello all :wave: we're using the rc version of pan...
# general
l
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
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
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
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
We tried, unfortunately our hacked plugin broke in too many places. We could not resolve it without 2.14
b
Ah yeah, plugins. Such a double-edged sword. Feel free to upstream if it makes sense, makes for less maintenance šŸ˜›
ā˜ļø 1
h
@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
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
+1 to Stu's
h
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
Thereā€™s nothing good that comes of removing filter. Iā€™d argue to add it back
h
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
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
I think that leaves the debate for "tombstone or code" open
h
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
I meant in general. 
filter
may be 20 lines, but not all goals that travel this path will be
w
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
Agreed. Itā€™ll be a trade-off between compatibility and maintenance burden
w
coke s all around šŸ˜ƒ
coke 1
f
Why a tombstone? What good does that do? Its only nice by comparison with depreciation with no breadcrumbs
b
Support and maintenance, primarily
f
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
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
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
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
(Still talking i_n general_)
f
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
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
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
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
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
Yeah, sorry, brought it up as a fun fact, not as a feasible approach in our case. Couldā€™ve stated that šŸ˜‰
l
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
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
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
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
./pants tailor '**'
is the command that will best approximate the old behavio that I've found
l
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
./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
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
yea
h
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
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
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
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
tailor2
, 
tailor3
ā€¦ ? šŸ˜› (as examples)
šŸ™ˆ 1
šŸ™‰ 1
šŸ˜… 1
Open in Slack
PreviousNext
Powered by