narrow-activity-17405
09/11/2020, 8:06 AMhundreds-father-404
09/11/2020, 8:11 AMnarrow-activity-17405
09/11/2020, 8:41 AMhundreds-father-404
09/11/2020, 4:20 PMBy tests I mean the same tests that are part of the packages (I’m using colocated tests) and normally are run using test target.Oh, that would be interesting. So, you would end up running the tests twice if I understand correctly; once normally like any other test, and then once in an integration test that will create the distribution and run those same tests, but using the distribution, rather than normal Pants mechanisms. Does that sound right? The reason I asked about what the distribution looks like is that it’s not as uniform as
binary
. For Python, ./pants binary
always creates a single Pex file no matter what. But for setup-py
, it depends on what you run. ./pants setup-py
creates a chroot with all the relevant files and setup.py
included. Meanwhile, ./pants setup-py -- bdist_wheel
will create a .whl
file. It’s not as obvious what format we should be using, as we don’t know ahead of time if you’re planning to create a wheel vs. the chroot vs. something else.witty-crayon-22786
09/11/2020, 5:06 PMhundreds-father-404
09/11/2020, 5:09 PMa thing that we found with bundle that might apply here as well is that moving more of the “configuration” of the distribution onto the target and out of the CLI args helps make them self-documenting.I was thinking the same thing. Right now, for example, with the
pantsbuild.pants
dist, we have to hardcode in a script what the arguments are to bdist_wheel
. It’d be better if that was memorialized in the BUILD filewitty-crayon-22786
09/11/2020, 5:26 PMOh, that would be interesting. So, you would end up running the tests twice if I understand correctly; once normally like any other test, and then once in an integration test that will create the distribution and run those same tests, but using the distribution, rather than normal Pants mechanisms. Does that sound right?it sounded like he was suggesting that the distribution contents should actually be placed on the pythonpath. the ambiguity is potentially problematic though.