I submitted a new ticket where pants seemed to have issues determining the tag version of a pytho wheel I need to provide as a dependency. I was advised to open a ticket for this issue as it's currently blocking me from upgrading the pants version to 2.11. Ticket: https://github.com/pantsbuild/pants/issues/15724 Thread: https://pantsbuild.slack.com/archives/C046T6T9U/p1653679339273349

That wheel tag is still bad. It combines non platform specific

py36

with a specific platform

linux...

. It might be good to include the full auditwheel command line and output you used to repair the wheel on the ticket.

Trying to avoid another channel in general, but after the suggestion to destroy lmdb_store (which solved my initial issue), the python code dependent on java.io now fails saying it can't access

libjava.so

which was never an issue before. I can run the same utests in pants 1.30 and have them work, so I'm curious if pants 2.11 needs some extra care when having python interact with java

Pants V2 is hermetic by default. Is the

libjava.so

linked through aid of

LD_LIBRARY_PATH

or the like? If so you'll need to tell Pants to allow that environment variable inside Pants executed subprocesses: https://www.pantsbuild.org/docs/reference-subprocess-environment#advanced-options

Sweet, that definitely help unblock me part of the way. I piped

LD_LIBRARY_PATH

and

JAVA_HOME

into the pants command, and that ran a bit further until I had to create some symbolic links from the openjdk path that the .so files are in to the python3.6/site-packages directory. Is there a good way to get pants to look for anything java in a different place? Right now what I have fails because the symbolic links exists, but I don't think python/pants have access to all of the java files needed to run the JVM