You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issues of this repo and believe that this is not a duplicate.
I have searched the documentation and believe that my question is not covered.
Hello!
From reading the docs and issues, it is rather unclear if Poetry supports working with multiple subprojects.
Like, I've got one big project A, which has several modules. I'd like to publish some of the modules as separate packages, and, preferably, with one command.
Sample project structure:
root_project_A:
module_1(should be packaged and published)
module_2 (should not be packaged)
module_3 (should be packaged and published)
pyproject.toml
How can I achieve this?
One solution is, of course, to make separate pyproject.toml for each of the modules to be packaged and run poetry build on each of them via some shell script. I could even make a poetry task for this.
But maybe there's some simpler solution?
I've read #161#356#167 and the subject is still a bit unclear.
@sdispater, is there any instruction on how to have two pyproject.toml on the same directory ? I would like to release two packages independently while avoiding deeply nested file hierarchy:
Another use case for which it would be useful to have two pyproject.toml in the same directory would be to release my_package (stable version) and my_package-nightly (released every night), each having their own name/version.
if you want to release two packages independently it is absolutely best-practice to keep the project folder and therefor the pyproject.toml separated, IMO.
For your second use case: I guess this could be realized via the planned plugin system.
i'm using Poetry to build gRPC bindings. I need to build multiple packages of bindings to be named and published separately, but the projects have identical dependencies, build scripts, test scripts, etc. They even share a common source directory (since the proto files form a single tree)
It would be really useful to have a single pyproject.toml file specifying multiple packages for this use case. The alternative (having a number of parallel projects) introduces a massive amount of duplication.
Reacted by Crocmagnon, Evangelos Pappas, Ajay M, Sreela Das, Kyle Putnam, Stephen Muchovej, Alex Ball, Guilhem Saurel, Joshua Hansen, superjcvd and 2 more
Activity
sdispater commentedon Mar 2, 2019
This is not supported by Poetry and the recommended approach is to have separate
pyproject.tomlfiles.Conchylicultor commentedon Jun 19, 2020
@sdispater, is there any instruction on how to have two
pyproject.tomlon the same directory ? I would like to release two packages independently while avoiding deeply nested file hierarchy:Rather than:
Another use case for which it would be useful to have two
pyproject.tomlin the same directory would be to releasemy_package(stable version) andmy_package-nightly(released every night), each having their own name/version.finswimmer commentedon Jun 20, 2020
Hello @Conchylicultor ,
if you want to release two packages independently it is absolutely best-practice to keep the project folder and therefor the
pyproject.tomlseparated, IMO.For your second use case: I guess this could be realized via the planned plugin system.
fin swimmer
danieleades commentedon Oct 28, 2020
another use-case for this-
i'm using Poetry to build gRPC bindings. I need to build multiple packages of bindings to be named and published separately, but the projects have identical dependencies, build scripts, test scripts, etc. They even share a common source directory (since the proto files form a single tree)
It would be really useful to have a single pyproject.toml file specifying multiple packages for this use case. The alternative (having a number of parallel projects) introduces a massive amount of duplication.
sinoroc commentedon Oct 28, 2020
Is this somehow related to the following?
I see that it is different, but I could also see some intersection between the two approaches for some use cases.
github-actions commentedon Mar 2, 2024
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.