https://pantsbuild.org/ logo
Join Slack
Powered by
<@U051221NF> are fine with me deleting the bash sn...
# development
h
@happy-kitchen-89482 are fine with me deleting the bash snippet on using 
python -m venv
, and simply go with 
./pants export
? NB that I'll make a code change so 
export
can handle mutliple resolves. https://www.pantsbuild.org/v2.10/docs/setting-up-an-ide#third-party-dependencies-python
Also I wonder if it's worth redesigning 
export
to be simpler...rather than 
::
, have it be something like 
./pants export --python-export-resolve=foo
But I'll do the current specs-based approach for now. We already have code from 
./pants repl
for how to handle multiple resolves, which I'm taking
Oh. @witty-crayon-22786, how about 
./pants export ::
creates N venvs, depending on # of resolves? We don't have 
InteractiveProcess
here, we can partition ourselves unlike 
repl
It does require reworking the API of 
export
to accommodate multiple folders, but we need that anyways
w
maybe… seems like solving the problem once for both 
repl
and 
export
will be important
doing something native for field filtering is going to be part of 2.11 and stabilizing parameterization
h
We can't fundamentally ever solve 
repl
other than "Run this command to run on a subset" 
export
is easy for us to create multiple venvs, no fundamental restriction. only time to implement. That is much more ergonomic than what I wrote in new docs
If you are using [multiple "resolves"](doc:python-third-party-dependencies), 
export ::
will error with instructions to choose which resolve to create the virtual env for. You can repeat this for each resolve to set up separate IDE modules for each.
w
correct. but for both 
repl
and 
export
, there is a specific choice to be made, i think.
what do you want to load into your IDE? what do you want a repl for?
adjusting export would mean needing to answer that question after exporting
as opposed to before
h
For IDE, I think we generate them all and then you as a human decide which to wire up to your IDE. You already have to wire it up
Do you know if BSP makes that wiring up automatic?
w
i do not… i’m not sure how multiple configurations/permutations of a build will work.
h
Fine with deleting the 
python -m venv
bit from the docs, yes
h
Cool. Opinions Benjy on what 
export
should do with multiple resolves? Another way of asking you that: you wrote about "to set up separate IDE modules for each." Do you know if that's actually possible?
@happy-kitchen-89482 Stu and I discussed more how 
export
should handle multiple resolves: • 
./pants export ::
creates 1 venv for each resolve. User can then point their IDE to whichever they want at the moment. • This requires renaming 
dist/virtualenv
to instead mention the resolve name...tbd how • Stu pointed out a downside is you may be doing more work than necessary, if you don't use some resolves. We considered instead eagerly erroring if >1 resolve is detected, and giving an error message like https://github.com/pantsbuild/pants/pull/14327. • Ultimately, we think doing the simplest and most correct thing is probably worth it, even if a bit slower. We can make it clear in docs how to generate for only one resolve Wdyt? This blocks 2.10 stabilization
h
I was imagining creating 1 venv for each resolve that is in play for that target set? Or all resolves by default? Either way we can add an option later to restrict to specific resolves?
w
yea, exactly.
h
So yeah that
h
Cool, yeah we're on the same page. PR coming soon 🙂
@happy-kitchen-89482 thoughts on this naming scheme? • if 
len([python].resolves) == 1
, stick with 
dist/virtualenv
• else, 
dist/virtualenvs/my-resolve
, 
dist/virtualenvs/another-resolve
Key insight is your point: "do the simple thing for 80% of users who don't need multiple resolves". This assumes that we will not have dedicated tool venvs, per https://pantsbuild.slack.com/archives/C0D7TNJHL/p1644397600652729. Not sure that's correct..
h
Exporting tool venvs is interesting but let's punt on that for now
What is the name of the single default resolve for the 80% of users?
I assume it has some hardcoded name
h
python-default
, so it would be 
dist/virtualenvs/python-default/
rather than 
dist/virtualenv/
h
So I think that, for continuity?
It's not an imposition to have that in the naming scheme
and the fewer special cases the better
h
Indeed, it would make it less painful if you go from 1 resolve -> 2. Does mean I need to figure out how to deprecate this naming scheme, but I can do that 🙂
h
I don't think we need to worry about that?
h
You don't think? Otherwise when you run 
./pants export ::
after the upgrade, PyCharm will keep using your old venv without you realizing that you need to go into IDE settings and update things. We could have a compromise where we scan 
dist/
folder to see if 
dist/virtulenv/
is there already, and if so log an ERROR or WARNING message that you must update your IDE. Wdyt?
(I'd love to not have to deprecate this more gracefully, very confusing to think about)
h
Yeah, a WARNING seems fine
🙌 1
h
@happy-kitchen-89482 any opinion if the interpreter constraints should come from the resolve vs. from the targets directly? From the resolve, we can inspect 
[python].resolves_to_interpreter_constraints
. The benefit of doing that is that you're less likely to have churn when running on 
./pants export dir1::
vs `./pants export dir::2`; it's possible for targets to be a subset of resolve's ICs, e.g. 
==3.8
vs 
>=3.7,<3.10
h
Probably from the resolve
Almost certainly, in fact
❤️ 1
for the reason you state
Open in Slack
PreviousNext
Powered by