Hi all. Has anyone encountered issues with local poetry libraries not getting detected by pants? I have a monorepo setup using poetry that successfully creates poetry lock files with all the dependencies I need, including my local libraries. However when I try to create pants lock files for my projects, my local libraries are always omitted. Should I be ignoring my pants lock files and basing my resolve off of my exported poetry requirements? I can't seem to find a reason in the docs as to why pants is missing or not parsing my local library pathing.

I'm not a poetry expert, so for clarification: by "local libraries" you mean that there is some way to configure poetry to consume local code as an editable install or similar?

Ah yes exactly. I have some local code with various utility functions shared throughout multiple other projects within my codebase. Within my

pyproject.toml

file for one of those projects,

my_project

, I have a relative path to an editable install:

my_library = { path = ".../.../.../libraries/my_library", develop = true}

, The usual poetry commands, poetry lock and install, correctly build this local library and let me use it throughout my project. However running

pants generate-lockfiles --resolve=my_project

omits

my_library

.

Clarifying the goal here (I work with Stefan): • We're in the process of adopting/integrating pants into a monorepo structure. The main language in the repo right now is python ◦ Until we've fully integrated / adopted pants, we want to allow developers to use "regular" python tools: pip, virtual environments, etc. • We have a couple "projects" in the monorepo already. We're working on setting up some internal "libraries" as well ◦ Libraries can use / reference other libraries ◦ Projects can use / reference libraries ◦ Nothing can use / reference projects What we're trying to do: Support local imports / dependencies using

pants

and "regular" python tools: pip, virtual environments, etc. Monorepo structure is currently something like this:

.
├── 3rdparty    (will eventually hold references to all external libraries)
│   ├── java
│   │   └── ivy.xml
│   └── python
│       └── requirements.txt
└── src
    ├── libs    (These can import one another; CAN NOT import projects)
    │   ├── java
    │   │   ├── library_1
    |   |   │   └── ...
    │   │   └── library_2
    |   |       └── ...
    │   │
    │   └── python    
    │        ├── my_lib_1
    │        |   ├── pyproject.toml    (and/or poetry lock file, whatever)
    │        |   ├── ...
    │        |   ├── my_lib_1
    │        |   |       ├── __init__.py
    │        |   |       └── ...
    │        |   └── tests
    │        |       └── ...
    │        └── my_lib_2
    │            ├── pyproject.toml    (and/or poetry lock file, whatever)
    │            ├── ...
    │            ├── my_lib_2
    │            |       ├── __init__.py
    │            |       └── ...
    │            └── tests
    │                └── ...
    │
    └── projects    (These can import from libs, and CAN NOT import each other)
        ├── java
        │   ├── project_1
        |   │   └── ...
        │   └── project_2
        |       └── ...
        │
        └── python
            ├── project_1
            │   ├── pyproject.toml    (and/or poetry lock file, whatever)
            │   ├── project_1
            │   |   ├── __init__.py
            |   │   ├── ...
            |   └── tests
            |       └── ...
            └── project_2
                ├── pyproject.toml    (and/or poetry lock file, whatever)
                ├── project_2
                |   ├── __init__.py
                │   ├── ...
                └── tests
                    └── ...

Currently, each project or library has its own pyproject.toml / requirements file that specifies third-party dependencies and local dependencies. So, for example, the pyproject for

project_1

might look something like this:

# pyproject.toml

dependencies = [
    "flask",

    # Internal tools
    "lib_1 @ file:///absolute/path/to/src/libs/my_lib_1"
]

Each of our developers will have a different path for lib_1 It seems like pants supports some relative pathing, or path templating: https://www.pantsbuild.org/2.19/docs/python/overview/third-party-dependencies#local-requirements To support "regular" pip-like functionality we've tried: • hatch/hatchling, which supports local dependencies: https://hatch.pypa.io/latest/config/dependency/#local • Stefan is currently also looking at poetry, which would support local dependencies as well https://python-poetry.org/docs/dependency-specification/#path-dependencies

I see. So, Pants is designed to consume internal code directly from the source tree, without any concept such as an "editable install" or any other way of creating a fake distribution. If your source roots are set up correctly then that side of things should "just work"...

Benjy - thanks for the thoughts. I'll take a look and report back