@happy-kitchen-89482 So, here's an idea. IDK if you guys have a Pants VSCode extension that you're building, but I would totes would love if you would do it openly.

I want to develop an extension, but I'd prefer to: 1. Not clash with the development you guys are doing. This also extends to doing useless work. 2. Ensure the solutions I come up with are solidified 3. Ensure the solutions are used.

I don't use VSCode myself, so I'd need to do more learning before expressing opinions...

But @witty-crayon-22786 has had some thoughts about it I think?

Or a plugin?

Is that what you mean by multiple worksapces?

I prefer to not work that way personally, but each repo can make their own decision.

I guess it would be great if we could come up with a way to support VSCode and other IDEs without requiring a particular repo layout.

Better IDE support is a much-requested feature

We're still figuring out what that means for the various leading IDEs out there

@enough-analyst-54434 I feel that

Yeah ... there's some thoughts I have around that. Autocomplete and quick commands (macros in VIM) are bae,

I couldn't live without autocomplete honestly. I have a condition that makes it so I have a short-term memory of a goldfish.

When writing python, it's kind of hard to manage cross-project dependencies.

For example:

(Editing for Formatting) 1. I have a bunch of separated util libraries that needed to be consumed by a bigger project. I was struggling with both installing the util projects into my bigger project. 2. I was also having issues with creating build processes and plugins for the code itself. It took me a few times of reading the tutorials to understand what I should be doing there, though I figured the actual steps for going about doing the most common things should be pretty well defined. 3. What I've come to do is rely on the DepHell project to create a

setup.py

then install an editable version of the micro-projects I'm including in a bigger project using their installation method.

Cargo has cargo-workspaces to help with that. Python doesn't

Might as well add some other things too: 1. While I'm trying to isolate the development of projects I want to not have to look at the other folders that are out there. Having some sort of isolation has been beautiful for development itself. It both helps for indexing and gives mental clarity. 2. For the isolation problem I have above, I use VSCode's multi-root workspaces. That surprisingly helps with project specific autocompletion (which is also a problem). I can choose a Python virtualenv per root meaning the completion I have doesn't bleed immediately over from other projects.

Which was kind of frustrating when I got started

if you workspace is entirely contained within one Resolve, then it is consistent from a typeahead perspective

it's all

python_library()

to pants for the most part, until you define a binary target

this does require some discipline with how i do my imports, but it's inspectible with tools like

./pants dependencies

& co

but that's what i mean for IDE integration being about making the IDE ask pants for things like this

because pants knows how to answer things like "what portions of this codebase do i need for this development task" better than any IDE does

Generally, the

pants.toml

file will tell where the sources. People could select how to interpret how they go underneath those sub folders

When my schedule actually clears up the plan was basically to fork the VSCode extension and try getting it to work with Pants