Question: are people using local Python requirements on their

main

branch, where you install from a file on the filesystem? John just landed support for VCS/git requirements with Pex lockfiles 🎉 We're trying to figure out how to prioritize local requirements

I may not have been clear elsewhere. We ~know people aren't today with Pants since Pex has never been able to subset (internal operation Pants uses) local project requirements. So I think the question is: have you been working around Pants lack of support for this?

We have a couple local requirements on our

master

branch that we install via

pip

(we’re still midway through our migration onto pants and haven’t gotten to the point of needing a work-around for it yet)

Here's an example illustrating how local file requirements may be needed whenever python packages communicate via the CLI instead of via

import ...

dbt

(https://www.getdbt.com/) is a key dependency. We have our own

dbt

plugin as first-party python code.

dbt

uses namespace packages to define plugins, e.g.

dbt.adaptors.{your_plugin_name}

. So far, fine. But `dbt`'s python api is experimental, so projects that interact with it prefer to use its CLI using

subprocess.Popen

. Without our first-party plugin being installed into site-packages along with the

dbt

package, the

subprocess.Popen

command does not have the current working directory in the python path, hence the

dbt

command is unable to see our plugin. So ideally, pants could include this plugin as a local file requirement. This is what you are starting to work on, correct? Existing workarounds: a) push our plugin to a pypi server separately and include as a 3rd party dep. This misses the point of having a monorepo. b) without pants, shamefully append the source root to

os.environ["PYTHONPATH"]

before calling to the CLI. Would love to hear any other ideas.

Yeah, that sounds right to me and indeed on the workaround with a) - that's a lot of ceremony. Thanks for weighing in!