Is there a trick on how to include pants itself in...
# plugins
i
Is there a trick on how to include pants itself in your
./pants export
venv?
w
if you’re set up as recommended in https://www.pantsbuild.org/docs/plugins-overview#building-in-repo-plugins-with-pants, it should be included in the resolve for your plugins
(…but, even if you aren’t: the
pants_requirements
target should act like a typical requirement, and be included in
export
for the resolve that it is in)
i
gotcha, yeah I need to have it in the general python export just due to ide limitaitons making dev a pain in the ass otherwise
hrm, when I add that plugin dev package and then the
pants_requirements
to the build files I get
Copy code
STDERR:
ERROR: Could not find a version that satisfies the requirement pantsbuild.pants.testutil<2.15,>=2.14.0a0
ERROR: No matching distribution found for pantsbuild.pants.testutil<2.15,>=2.14.0a0
on
pants generate-lockfiles
h
i
when I do
Copy code
pants_requirements(name="pants", testutil=False)
I get the same erro but for pantsbuild.pants 😕
h
What are the interpreter constraints in your repo?
i
Copy code
14:59:16.09 [ERROR] 1 Exception encountered:

  ProcessExecutionFailure: Process 'Generate lockfile for python' failed with exit code 1.
stdout:

stderr:
pid 70438 -> /Users/kaelten/.cache/pants/named_caches/pex_root/venvs/cac1718c056bb509f51fcdcc0c376b33deaaa8ec/f29ceda0a4b900d6737ee931e12a27b2830c8fdd/bin/python -sE /Users/kaelten/.cache/pants/named_caches/pex_root/venvs/cac1718c056bb509f51fcdcc0c376b33deaaa8ec/f29ceda0a4b900d6737ee931e12a27b2830c8fdd/pex --disable-pip-version-check --no-python-version-warning --exists-action a --no-input --isolated -q --cache-dir /Users/kaelten/.cache/pants/named_caches/pex_root/pip_cache --log /private/var/folders/3g/ld5vzjf11w16v0757cxqkvhh0000gn/T/pants-sandbox-gEdk8c/.tmp/pex-pip-log.8zbj93ad/pip.log download --dest /private/var/folders/3g/ld5vzjf11w16v0757cxqkvhh0000gn/T/pants-sandbox-gEdk8c/.tmp/tmpcffkv417/Users.kaelten..pyenv.versions.3.10.2.bin.python3.10 boto3<1.25.0,>=1.24.16 fastapi<0.86.0,>=0.85.0 pantsbuild.pants<2.15,>=2.14.0a0 pydantic<1.11.0,>=1.10.2 rich<12.6.0,>=12.5.1 structlog<22.2.0,>=22.1.0 uvicorn[standard]<0.19.0,>=0.18.3 --index-url <https://pypi.org/simple/> --retries 5 --timeout 15 exited with 1 and STDERR:
ERROR: Could not find a version that satisfies the requirement pantsbuild.pants<2.15,>=2.14.0a0
ERROR: No matching distribution found for pantsbuild.pants<2.15,>=2.14.0a0
h
pantsbuild.pants requires >=3.7,<3.10
i
ah, and I'm on 3.10.2 for my project 😕
so this means I can't get a venv exported that I can use in my IDE for the plugins because of that...
w
not so: see the link i included at the end of this thread: https://www.pantsbuild.org/docs/plugins-overview#building-in-repo-plugins-with-pants
👍 1
you just need to use separate resolves for your plugins and the rest of your code.
i
which means I can't develop it in the same IDE workspace as the rest of my code.
because pycharm doesn't support multiple venvs
w
because pycharm doesn’t support multiple venvs
you can open separate “projects”, i think?
i
I can't think of a clean way to do that given one of the projects would be nested under the other
Given we're about 2 weeks away from python 3.11 being out and being the new current, when can we expect pants to catch up? Last I checked there hand't been any updates on github in a few months.
w
to be clear: even if Pants was ported to* Python 2.11 already, you still probably wouldn’t want to mix the requirements of your plugins in with your application code: that’s the reason we suggest putting them in another resolve (less so the python interpreter versions)
Pants requires a particular version of
requests
for example
i
I get that, and I wish python had smarter dependency management, but the state we're in is making me (who's honestly excited about the promise of pants) worry that I'm just going to open up an unsustainable amount of complexity on my team if we were to try to adopt pants. The only reason I'm even going down the plugins route is any sufficiently mature workflows would require plugins to be made, potentially many . 😞
w
The only reason I’m even going down the plugins route is any sufficiently mature workflows would require plugins to be made, potentially many .
for sure: happy to help with that. and i think i’ve seen other threads listing out some of the workflows you’ll need working. but particularly if you’re going to have a bunch of code dedicated to something, it’s worth setting it up rigorously, which in this case means using a separate resolve / treating the plugins as a separate/incompatible project
h
Yeah, I think segregating plugin-specific requirements from the rest of your codebase’s requirements is probably beneficial to the rest of the team who don’t need to deal with modifying those plugins?