Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

back to this topic: it's not clear why plugin resolution needs to trigger transitive dep resolution in this case

for one thing: contrib modules don't have transitive deps beyond pants itself, afaik

so... should plugins be resolved intransitively?

not sure - <@U04S45AHA> may be able to shed some light?

rolling all the way back to `release_1.4.0.dev3`, the translated `egg` file for the plugin does contain `__init__.py` files

now checking whether a `whl` translated by `release_1.4.0.dev3` doees as well.

interesting. in that release at least, the tar.gz is not translatable to a `whl`

```Exception message: Package SourcePackage('file:///Users/stuhood/src/pants/dist/pantsbuild.pants.contrib.android-1.4.0.dev3.tar.gz') is not translateable by ChainedTranslator(WheelTranslator, EggTranslator, SourceTranslator)```

there should be some error text abouve that explaining the cause

on stdout? ... i only have stderr in this context

Catching up, but in terms of <https://github.com/pantsbuild/pants/issues/4877>, the issue is for Interpreter (capital I). We call resolver.resolve w/o passing an Interpreter and so PEX defaults to creating one from our sys.executable binary

I believe it can be the case that that binary will not have wheel even though our venv, which links that binary, has it

Basically we're not setting up an Interpreter with extras like we otherwise do elsewhere

Its a crappy resolver.resolve call taking shortcuts

And about eggs without __init__.py - I think this can be standard

Is there no some .pth thing trick that happens sometimes where all the namespace stuff gets injected?

Ok, thanks. from what i can tell: translated eggs do correctly have __init__.py files in this context

(on both dev3 and the dev13 i'm prepping)

we were thinking of just calling `wheel` a pre-req and then slotting wheels into the resolver precedence so that we could resolve directly against binary deps on pypi

was talking to kris offline: he suggested i try to reproduce the missing __init__.py files in a more vanilla pex invoke

Right, but Intepreter used by pex needs that `wheel` pre-req and I'm pretty sure it won't find it by magic

IOW we resolver.resolve-multi in python backend tasks correctly

in this case, i think we're just taking the resolved entries and putting them on pants' own sys.path ?