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

hundreds-father-404

01/28/2022, 8:15 PM
@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

witty-crayon-22786

01/28/2022, 8:16 PM
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

hundreds-father-404

01/28/2022, 8:19 PM
Do we need to fix JVM for 2.10 also? I'm pretty sure having
compatible_resolves
on
jvm_source
is not correct
w

witty-crayon-22786

01/28/2022, 8:23 PM
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

hundreds-father-404

01/28/2022, 8:33 PM
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

witty-crayon-22786

01/28/2022, 8:34 PM
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

hundreds-father-404

01/28/2022, 8:37 PM
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

witty-crayon-22786

01/28/2022, 8:38 PM
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