-
-
Notifications
You must be signed in to change notification settings - Fork 631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dirty python packages in dist #11812
Comments
Would a warning have helped perhaps? I suspect there are cases where you want to run ./pants package multiple times sequentially without Pants erasing the prior runs. |
A warning would be nice, and maybe even a |
Just thought to clarify, that if you run seq with different targets, it wouldn't be an issue, as I suggest to only remove the target that is about to be written. So any seq run ought to produce the same result, everything else unchanged. Not sure if that came across in my previous post. |
Oh! I did not realize that's what you were proposing. What are you creating here? I think we hadn't considered this as being necessary because |
I use that to get a virtualenv where I can install several (all) my dists in to play around and test with. Couldn't find there is a better/recommended way of doing this..? EDIT: EDIT2:
|
It depends on what sort of playing around you do. If its experimenting in a repl, then
|
Yeah, the repl doesn't really offer the cli entry point experience I'm after here. |
Yeah - you'd need to re-create it. The develop mode trick is most closely matched by
|
Cool, will have to give that a spin, see how it goes :) EDIT: Nice, that runs it cool, only one thing missing, and that is that the pex file doesn't include my dists as wheels, but as source only.. so I can't dynamically load them using setuptools entry_points.. :/ |
Not sure this is the right issue, but this discussion has been the closest to my problem: I have a mono repository setup with VSCode and many poetry projects. We used to create a venv with all locked dependencies and the packages in the repository as editable installs. The nice effect of this was that VSCode then does auto completion, but also debugging and test runs are easy to configure and changed code is always reflected. To me it seems that the debug/development workflow is completely missing from pants, at least when I want to use other tools/IDEs that expect a venv with all the third party dependencies installed. Is there some workaround or is this planned for the near future? I am not sure I fully understand the PEX_MODULE or PEX_SCRIPT hint above. |
Hey @malte-klemm-by ! I think that this issue is mostly unrelated to what you are trying to do: to set up an IDE for a Pants repo, see https://www.pantsbuild.org/docs/setting-up-an-ide. The only way that this issue might affect your IDE setup would be if you are using codegen (generated code): in that case the |
Unrelated to this issue, yes. However the reason I got here is related. I too was looking for a good dev/debug feedback-loop. I think we can do better here, will open dedicated ticket if none exist when I get back from vacation. |
Hi @stuhood, first of all thanks for the quick answer. I had read that section in the docs, but the setup described there is not really ideal for vscode. First, adding each root to the vscode settings is something we had to do in the past and didn't work well (we have around 40-50 root folders and making sure these settings work with every developer proved to be quite error prone). Secondly, setting up the remote debugger in VSCode is always a bit more fiddling than using the direct My hope was somehow that the I had a look at the plugin documentation and have some ideas how I could get to the expected setup. I will have a look at it after my vacation and will add to the discussion on the new ticket / join the slack to discuss my setup and give some feedback. In our team we have used multiple mono repo approaches so far and the biggest downside has always been the dev/debug setup so I am happy to improve as pants v2 looks really promising apart from that aspect. |
Ah, thank you both for the clarification and investigation!
PEX does support a venv execution mode, and it is enabled by default for most internal PEXes that are built (including those used for tests). One thing that can help with investigating the test sandboxes is to run with |
Fixed by #18639 |
When running
./pants package ::
any previous packages in./dist/
ought to be removed first in order to clean out old files for any target packages.I have noticed that I have to manually remove them in case I re-organize my code, the now no longer referenced files are otherwise still left in the tree.
The text was updated successfully, but these errors were encountered: