One thing that I have tried is

resources(

name="spylizard",

sources=["spylizard.so"],

)

python_sources(

overrides={

"solver_spylizard.py": {

"dependencies": [

":spylizard",

],

}

}

)

But this does not solve the problem: ModuleNotFoundError: No module named 'spylizard' When the binary is in .pyenv, and script is executed with python, module is imported.

If the

spylizard

package provides

spylizard.so

as part of its installation, then you want to add

spylizard

as a 3rd-party requirement in your code (e.g., in requirements.txt) and generate it into your lockfile if you're using lockfiles. You can't rely on it existing in an interpreter's site-packages, because Pants (via Pex) takes great pains to scrub those from its working set.

There is work under way to support "provided dependencies" - that exist in the interpreter's site-packages and are not installed by Pants, but this is not supported yet.

Following these instructions: https://github.com/halbux/sparselizard-users/tree/main/api/python

I can't really add it to requirements.txt, since it is not pip installable. I also can't build a wheel for it.

So you manually build it and copy it to... where exactly?

why .pyenv?

Interesting, hmm

I checked to see if https://pypi.org/project/spylizard/ does what you want but it appears to be a broken work in progress, so let's ignore that.

One thought is to treat this is another use case of @flat-zoo-31952’s work on provided dependencies.

I'll think on this one for a bit

The "proper" way would be to run the steps in https://github.com/halbux/sparselizard-users/tree/main/api/python in a series of adhoc_tool or shell_command invocations, but even then I don't see how we could install it into the site-packages afterwards

Without a plugin

this may require a custom plugin

But I will chew on this for a bit, it's an interesting case

I don't really have free time to devote to this kind of work, sadly. There was just an idea for adding a union rule to python dep inference so that we can non-pip types of 3rd party deps

Then you'd have to write a plugin for finding your provided dep (probably would be left as a plugin hook, since this could vary so much depending on your use case)

And then I think newer version of PEX can be told to just ignore some of these deps and run them from the environment

If you're interested in contributing, I could walk you through this in greater detail, I just don't foresee having much time to sit down and code it myself