wooden-thailand-8386
10/19/2020, 8:16 PMpyproject.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….
hundreds-father-404
10/19/2020, 8:19 PMwooden-thailand-8386
10/19/2020, 8:21 PMhundreds-father-404
10/19/2020, 8:22 PMpyproject.toml
for it to understand first-party code?wooden-thailand-8386
10/19/2020, 8:25 PMpyproject.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
libraries/
libA/
pyproject.toml
libA/
__init__.py
cool_lib.py
hundreds-father-404
10/19/2020, 8:33 PMthat 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.wooden-thailand-8386
10/19/2020, 8:33 PMhundreds-father-404
10/19/2020, 8:38 PMfresh-architect-74417
10/19/2020, 8:39 PMdist-packages
directory