I’ve got a change that makes pants do editable installs of all relevant `python_distribution`s when exporting a mutable virutalenv (which essentially turns pants into a PEP-660 frontend and backend - albeit delegating a few pieces of that to pip and to the configured PEP-517 backend). Or at least I’ve got all of the export tests passing now, including integration tests. I haven’t used this on the st2 repo yet 🙂 Scope of my change: This is only possible fore mutable venvs, so symlinked venvs will not get this feature. Tool resolves (which are deprecated in 2.16) do not ever have dists, so this does not apply there either. And I’m not touching the legacy export codepath (where you do

export <addresses>

) that will stay as is; this will only apply when using

export --resolve=

). So, here’s my question: Should we have a new export option to enable/disable editable installs? If so, should it default to enabled or disabled (disabled is the backwards compatible option)? Or should we always do editable install of dists when exporting a resolve that includes dists?

what’s the downside to having it always enabled? It’s been quite a while since I needed this, and it may come up again but not something I’d need on a regular basis for sure.

python_distribution

does not have a

resolve

field. So figuring out which resolve a

python_distribution

belongs to is expensive: calculating the owned deps of all distributions, and for each distribution, look through those deps until one of them has a resolve field, and use that for that dist’s resolve. Plus there’s the cost of building the PEP-660 wheels - if the configured PEP-517 build backend doesn’t support the PEP-660 methods, then it falls back to a method that is, sadly, optional in PEP-517. If that method isn’t there, then it falls back to telling that backend to build the whole wheel, and then it extracts just the dist-info directory from it and discards the rest. So, installing these editable wheels isn’t free. It’ll slow down the export, though I’m not sure by how much.

hmm… feels like an option is a good idea then; possibly defaulting to

disabled

based on the relatively few times we’ve seen this feature requested..?

Yeah. I would enable that option in pants.toml for the st2 project, but 🤷 others apparently don’t need it as much?

Is it a property of the resolve though, or of the python_distribution?

oh. I hadn’t thought about adding a field to

python_distribution

to control inclusion.

Oh, right, this is when exporting an entire resolve

We need to be able to generate the

dist-info

directory with the PEP-517 backend, so we need the

provides=python_artifact()

details.

gotcha

Technically, we could also inject a

.pth

file that just adds all of the source roots (that contain code in the exported resolve). But people can set PYTHONPATH for that as well. The major value of editable installs is to get the

dist-info

details.