Is there any way how can I run tests against distribution targets? It would be good to test them before uploading to pypi - I can imagine that for instance, some dependency might be missing...

Automated tests, right? Similar to the new feature for using a built binary in a test? No support atm, but it’s an interesting idea. One main question is what does a “built” setup.py distribution look like to you? Is it a .whl file, for example, or the generated chroot with the setup.py in it?

Yes, automated tests. I haven't set up a workflow for publishing built packages yet. So far I was only using setup-py goal to create packages under dist directory. It already happened that I forget to specify something in the BUILD file which leaded to uncomplete distribution - because of this, I was thinking that it would be useful to run tests against distributions - to make sure they are ok before uploading them to pypi. I don't mind (probably) in which form distributions will undergo tests.

By 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.

a 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.

a 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 file

“enshrined”