zlacker

>>ingve+(OP)
A lot of the problem seems to be driven by a desire to have editable installs. I personally have never understood why having editable installs is such an important need. When I'm working on a Python package and need to test something, I just run

python -m pip install --user <package_name>

and I now have a local installation that I can use for testing.

>>pdonis+FYm
That would you require to make re-installations if your local app you develop against after every code change. Very few people will want to do that and it’s potentially very slow.

It’s also a step not needed by most other ecosystems.

>>the_mi+c1n
> it’s potentially very slow.

Potentially, perhaps. But it's certainly not for the cases where I use it: a pure python package, whose dependencies are already installed and are not changing (only the package itself is). Under those conditions, the command line I gave takes a couple of seconds to run.

>>pdonis+s4n
I.e. orders of magnitude longer

>>pauldd+kwn
Orders of magnitude longer than what?

>>pdonis+xco
Than editable installs. The main sentry app takes ~10 seconds to pip install. I would not want to run that every code change. Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.

>>the_mi+rVo
> The main sentry app takes ~10 seconds to pip install.

Which is much longer than the "couple of seconds" I gave for my use case. Yes, if it takes that long, I can see how you would want some alternative.

> Also more painful to debug because the filenames in the stack trace no longer match to what you have open in your editor.\

Why not? If you do a fresh install, everything should match up. It seems like this problem would be more likely with an editable install, if things aren't kept in sync properly.

>>pdonis+vQr
> Why not? If you do a fresh install, everything should match up.

Absolutely not. The file names in stack traces will be from the site-packages folder in the venv instead of the local checkout.