What would be a good pattern for local development using a monorepo? I ended up adding a “main”

pyproject.toml

that creates a virtualenv and add all the projects and libs so VSCode/PyCharm can easily find it and allow autocomplete and stuff like that. But in order for that to work the structure of the libs and projects have to follow the pattern of a “python package” so I have a `pyproject.toml`for each lib/project setting up it’s name.. source code.. etc.. it is working but looks quite verbose.. I was wondering if there’s any way to make this “slim” but keep the IDE stuff.. specially considering how many folks on my team still thinks that they have to import the whole folder structure like:

projects.projectA….

See https://www.pantsbuild.org/docs/python-third-party-dependencies#tip-set-up-a-virtual-environment-optional for a little script to create a virtualenv that teaches your IDE about your third party dependencies For source code, with Pycharm, I also have to teach Pycharm what my source roots are, like “src/python”. Then, Pycharm recognizes everything

isnt that only for 3rdparty?

Yeah, that only teaches the IDE about third party. I haven’t used VSCode in some time, but do you need to use a

pyproject.toml

for it to understand first-party code?

Well.. the way I’ve done is IDE agnostic, I’m telling my monorepo

pyproject.toml

about all 3rdparty dependencies and first-party. For the first-party I use relative path that points to that lib/project’s folder which also must have either a

setup.py

or

pyproject.toml

that way my virtualenv will have everything and the first-party will be in “edit” mode.

okay, if you want to teach the IDE about your code via an editable first-party distribution, I can’t think of an alternative approach. Using

./pants package

(formerly

./pants setup-py

) wouldn’t work well because it won’t be in edit mode, so won’t catch new changes. I think you’ll have to pick your poison here: 1) the boilerplate of

pyproject.toml

in each project 2) setting up each distinct IDE to recognize your first party code using their mechanisms for them Either seem fine, but I’d personally bias towards #2 to avoid including in version control artifacts only designed for the IDEs.

So I’m not completely crazy here haha

Hah no, people use both approaches, and I think often #1 if they’re not using a build tool like Pants or Bazel. The 3 orgs I’ve been at who use Pants all use approach #2. Each has had a little wiki/README about how to set up the project with IDE X, Y, Z

@wooden-thailand-8386 I have a vagrant file that setup a virtualbox machine with the right python version