Hi, I am trying to find out whether editable insta...
# general
Hi, I am trying to find out whether editable installs as specified in PEP 660 or as supported by setuptools are supported by pants or how something similar can be achieved using pants.
Some more information on our use cases: The first one is that we currently have a virtualenv in our repository that we install the packages to in an editable mode. Using that venv, we can then quickly run our entry_points or test things on the interactive python shell. Changes to the code are immediately reflected in the venv. The next use case is that we have an application that spawns a docker container, mounts our repository into it and installs it in editable mode as well and then shells into the container. This also exposes several endpoints inside the container that we can call while at the same time editing the code and therefore the available functionality. These things are rather deeply integrated in our workflows and it would be great to achieve the same with pants without major hacks and workarounds
Editable installs are complicated in the pants world - they don't play nicely with repeatable, hermetic builds (think about how they would interact with caching...)
For your first use case, there is the
flag on `repl`: https://www.pantsbuild.org/docs/reference-repl#section-restartable
So as you edit the repl restarts automatically
but I don't know if that's a great user experience, since you end up with a fresh repl each time, and have to re-import everything
and also I'm noticing that it seems to not work well with the console, at least on my macos
As for your second use case, how do you envision Pants fitting in here? Ignoring what's currently possible, what would the ideal workflow be like?
Changes to the code are immediately reflected in the venv.
I guess you need to re-import any code that has changed?
Hey, I had to think about this a bit. I think for the first use case, it's fine to have restart the repl after doing some changes, I don't even know if venv is able to patch into a running one. I think import will always have to be called again. For running the commands, I think it's fine to just run them using
./pants run
. I checked it out and I was afraid before that it would have to build the cache again after a change, but the second run even with code changes in between is super fast. One question there. Is there a way to define a target to be callable for example as
./pants run main-app
instead of
./pants run project/src/apps/main:main-app
or something similar? For the second use case, I think it would also already work using the
./pants run
command, if we mount the cache into the docker container 🤔 Here the ideal workflow (as it happens right now) is that we start up our docker container (with mounted code dir) with interactive shell and on startup a venv is created and activated that has editable installs of our code in there. I can now run a command like
if it's defined as an entry-point in e.g. my
. I now see, that I need to change something to the code, can do that outside the container and run the command inside the container again (which will have the latest changes included). Pants could be used here to generate setup.py files that allow for the editable install or even allow you to extend the
command to allow you to also do editable installs into the exported venv. But I think with the pants-cache mounted as well, we could call
./pants run sth
instead of the direct call through venv and deal with it having to cache the dependencies etc once for each command. That is pretty much equivalent to the purpose that the venv basically serves (to have the dependencies loaded and apps ready to be executed). This is probably the more compatible solution here.
Re the command-line shortcuts, you can define aliases using this option: https://www.pantsbuild.org/docs/reference-cli , if you don't mind hardcoding a list of aliases in config.
Or you can have a root-level BUILD file that contains pex_binary targets that point to code deeper in the tree, and use
./pants run //:main-app
and so on
Awesome, thanks, will try those options! 👍 I think the aliases will be very useful