i don't actually know anything about the codepath... will look.

looks like the plugin resolver constraints itself to eggs and sdists only here: https://github.com/pantsbuild/pants/blob/master/src/python/pants/init/plugin_resolver.py#L82

probably just outdated? can’t think of a reason to use eggs but not wheels.

trying to repro w/ that patched for wheels

this patch got me to a different error:

--- a/src/python/pants/init/plugin_resolver.py
+++ b/src/python/pants/init/plugin_resolver.py
@@ -11,7 +11,7 @@ import os
 
 from pex import resolver
 from pex.base import requirement_is_exact
-from pex.package import EggPackage, SourcePackage
+from pex.package import EggPackage, SourcePackage, WheelPackage
 from pkg_resources import working_set as global_working_set
 from pkg_resources import Requirement
 
@@ -79,7 +79,7 @@ class PluginResolver(object):
     # When bootstrapping plugins without the full pants python backend machinery in-play, we are not
     # guaranteed a properly initialized interpreter with wheel support so we enforce eggs only for
     # bdists with this custom precedence.
-    precedence = (EggPackage, SourcePackage)
+    precedence = (WheelPackage, EggPackage, SourcePackage)
     <http://logger.info|logger.info>('Resolving new plugins...:\n  {}'.format('\n  '.join(self._plugin_requirements)))
     return resolver.resolve(self._plugin_requirements,
                             fetchers=self._python_repos.get_fetchers(),

aha!

doing a code review... will look in a second.

oh, duh the reasoning is right there in the comment above it

seems like we could just require wheel be installed as a pre-req (doc change), since it will likely make transitive resolution much easier

theoretically the plugin resolver could validate that by attempting to

import wheel

in a try/except block and erroring with something along the lines of ‘please install wheel’

mm... gotcha.

and in the context of pants running in a venv (via https://github.com/pantsbuild/setup/blob/gh-pages/pants usually), we could do that automatically, presumably?

@rough-minister-58256: so perhaps i re-enable resolving using wheels with that check, and then ensure that https://github.com/pantsbuild/setup/blob/gh-pages/pants puts

wheel

in the

venv

?

it's not clear why

$ gr 'wheel' 3rdparty/python/
3rdparty/python//requirements.txt:wheel==0.29.0

isn't sufficient to ensure that pants has wheel on the path though...

it looks like that explanation is quite old... from 2015. it's possible that pants just didn't depend on wheel at that point?

hm, no. pants itself already had a dependency on wheel before that line was added, so it's not clear to me that your edit to allow WheelPackage wouldn't just work. @enough-analyst-54434: do you have more context there?

(but yea, i repro the different failure after that change)

it’s a bootstrap dependency - pex can’t resolve/install/etc wheels without

wheel

installed before hand

oh, installed... ie not just on the PYTHONPATH?

but yeah maybe just pip installing into the venv in pre-python code is sufficient

can’t think of why that wouldn’t work - maybe we’re just making affordances for folks not using these venv bootstrapping routines?

ok. so i'll operate under the assumption that that should work, and see if i can make progress on the next error tonight.

@rough-minister-58256: is there an explanation somewhere of how a

whl

is actually loaded? does wheel inject itself into python module resolution such that it will actually load one right off the path? the result of the resolution seems to be a

whl

file on the PYTHONPATH, which is then not loaded

wheels are meant to be ‘installed’ technically, but 95% of them work with just being on the PYTHONPATH

pex was recently fixed to properly install wheels at runtime

@rough-minister-58256: i think i see something significant:

pantsbuild.pants.contrib.android-1.4.0.dev13.tar.gz

contains the relevant

__init__.py

files for

pants.contrib.android

to do the right thing. but the wheel that ends up on the path (i guess due to the pex resolver converting the tar.gz into a whl) does not contain

__init__.py

files

am i correct that that is how that whl is being created?

it’s likely “translating” (in pex parlance) the sdist to a wheel (bdist) via e.g.

python setup.py bdist_wheel

yep