https://pantsbuild.org/ logo
w

wooden-thailand-8386

10/19/2020, 8:16 PM
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….
h

hundreds-father-404

10/19/2020, 8:19 PM
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
w

wooden-thailand-8386

10/19/2020, 8:21 PM
isnt that only for 3rdparty?
h

hundreds-father-404

10/19/2020, 8:22 PM
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?
w

wooden-thailand-8386

10/19/2020, 8:25 PM
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.
the problem with that is that the folder structure ends up looking like this:
Copy code
libraries/
   libA/
      pyproject.toml
      libA/
        __init__.py
        cool_lib.py
h

hundreds-father-404

10/19/2020, 8:33 PM
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.
👍 1
w

wooden-thailand-8386

10/19/2020, 8:33 PM
So I’m not completely crazy here haha
h

hundreds-father-404

10/19/2020, 8:38 PM
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
f

fresh-architect-74417

10/19/2020, 8:39 PM
@wooden-thailand-8386 I have a vagrant file that setup a virtualbox machine with the right python version
Pycharm runs pants app directly from the vagrant file
It requires the pro version of pycharm
I symlink pants root directory in
dist-packages
directory
10 Views