https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> (and anyone else!) re timing of 2.10 ...
# development
h
@witty-crayon-22786 (and anyone else!) re timing of 2.10 stable release & Python multiple (disjoint) lockfiles. I think within ~1 week we can ship it as a stable feature. Do we want to gate the release on this?
By end of today or Monday, we'll have multiple disjoint lockfiles working for everything except for 
python_distribution
, including 
test
, 
run
, 
package
, and Pylint/MyPy. Remaining work we need in order to stabilize: • Add lockfile validation, which is mostly implemented, just needs good error messages • Figure out what the heck to do with 
python_distribution
Stuff we do not have to do for 2.10: • Switch from Poetry to Pex for lockfile generation & consumption • Implement https://github.com/pantsbuild/pants/issues/14293, which is highly desirable for multiple overlapping resolves but is irrelevant for disjoint resolves • Your parametrization design doc We can't require using resolves imo until we switch to PEX thanks to its eventual handling of VCS requirements + 
[python-repos]
. But, we can get this into production, it should generally be much better than status quo w/ constraints file.
w
i’m about to make a comment on the parameterization doc that would suggest adjusting the syntax of python_requirements again =x … but other than that, i don’t know of any blockers
👍 1
h
Do we need to fix JVM for 2.10 also? I'm pretty sure having 
compatible_resolves
on 
jvm_source
is not correct
w
i’m about to make a comment on the parameterization doc that would suggest adjusting the syntax of python_requirements again =x
here
@hundreds-father-404: no… JVM won’t be stabilizing this release
👍 1
h
here
I gotta think more about this with an open mind before I reply hah. Thanks for the suggestion (I want to try writing out some real world examples)
Timeline wise, this question is really important to figure out though. We should not have 
use_deprecated_python_macros
and the 
update-build-files
fixer in stable 2.10 if we are getting rid of or changing 
#
syntax (It's fine that Go and JVM already use it as those are experimental)
w
I want to try writing out some real world examples
yea. probably boils down to what the key for a requirement or go-mod entry would be
Timeline wise, this question is really important to figure out though.
yes.
h
Initial reaction: a target generator never == a generated target. 
poetry_requirements -> python_requirement(s)
Unlike parametrization, which is 
python_requirement -> python_requirement(s)
Another big difference is that target generators are addressable and targets on their own. Iiuc, parametrization is more like a macro-syntax that converts 1 BUILD file entry into N targets. The BUILD file entry is not addressable itself
w
sure. but i’m not sure that that distinction is relevant to the address syntax
@happy-kitchen-89482, @enough-analyst-54434: would welcome your input on whether we should merge the 
#
(“generators”) syntax with the proposed parameterization syntax: there is some discussion in this slack thread, but more on this comment in the Parameterization doc: https://docs.google.com/document/d/1mzZWnXiE6OkgMH_Dm7WeA3ck9veusQmr_c6GWPb_tsQ/edit?disco=AAAAUx99usw
also, @proud-dentist-22844, @curved-television-6568: if you have any more thoughts.
the relevance of the timing is that 
#
is not yet used in stable code: only in 
go
thirdparty, and for 
python
thirdparty soon (
2.10.0rc0
). so if we’re going to change it, we’d need to do so before cutting 
2.10.0rc0
in the next week or two
👍 1
Open in Slack
PreviousNext
Powered by