The idea of using poetry is to replace the custom in-requirements.txt/requirements.txt machinery with something more standardized.
Poetry works well with one project where a project maps to the unit of packaging (one project => one wheel). However, we have a monorepo with several projects, each of which should be in separate wheels. Each of those packages will be installed in the same virtualenv, however, so we want a global dependency lock.
Poetry doesn't handle monorepos yet. It now has a plugin system, so maybe that could be used to add this as described in these comments:
The pants experiment has panned out nicely, so I'm leaning towards just using that. Plus pants/pex lockfile is more robust than the poetry lockfile as it handles git repo deps as well.
The idea of using poetry is to replace the custom
in-requirements.txt
/requirements.txt
machinery with something more standardized.Poetry works well with one project where a project maps to the unit of packaging (one project => one wheel). However, we have a monorepo with several projects, each of which should be in separate wheels. Each of those packages will be installed in the same virtualenv, however, so we want a global dependency lock.
Poetry doesn't handle monorepos yet. It now has a plugin system, so maybe that could be used to add this as described in these comments: