Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow non-package dependencies to be installed when package-mode = false #9169

Closed
RiccardoRomagnoli opened this issue Mar 17, 2024 · 8 comments
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged

Comments

@RiccardoRomagnoli
Copy link

RiccardoRomagnoli commented Mar 17, 2024

Issue Kind

Change in current behaviour

Description

I need to manage non-package dependencies is a distributed way. I have multiple "root" pyproject.toml which references different shared code, every grouped shared code has its dependencies in another pyproject.toml.

I see that with #1132 #8650 I can set my "roots" pyproject to package-mode = false but then when referring to other local dependencies like this dependencies = [ mydep = { path = "../shared/mydep"} ] I get:

RuntimeError: Building a package is not possible in non-package mode.

But I don't want to build mydep I just want to install his dependencies since I also specify package-mode = false there.

Impact

This brings more flexibility & scalability on non-package projects

Workarounds

Install local non package dependencies as packages. This brings in all the boilerplate of packages when not needed

@RiccardoRomagnoli RiccardoRomagnoli added kind/feature Feature requests/implementations status/triage This issue needs to be triaged labels Mar 17, 2024
@radoering
Copy link
Member

That's out of scope. Dependencies have to be packages.

@radoering radoering closed this as not planned Won't fix, can't repro, duplicate, stale Mar 17, 2024
@RiccardoRomagnoli
Copy link
Author

RiccardoRomagnoli commented Mar 17, 2024

@radoering Could you elaborate more on the reason why dependencies needs to be packages?

@RiccardoRomagnoli
Copy link
Author

@thejohnfreeman what do you think?

@finswimmer
Copy link
Member

Could you elaborate more on the reason why dependencies needs to be packages?

This is how it works in the python ecosystem, so this is not a Poetry thing.

@RiccardoRomagnoli
Copy link
Author

RiccardoRomagnoli commented Mar 17, 2024

Poetry already expanded in the package-mode false possibility, I don't see why it can't be expanded in regards of non-package dependencies. Still, I would appreciate if you can elaborate more on the fundamental reasons for which this is not feasible.

Poetry presents it self as "Poetry is a tool for dependency management ... ", I think my feature request is inline with Poetry vision.

@neersighted
Copy link
Member

neersighted commented Mar 17, 2024

import statements are resolved in the sys.path, which is a set of paths where packages are installed, plus (typically) the current working directory. To import from another project not in sys.path or the CWD, you therefore must have an installed package.

Similarly, Poetry recursively resolves a dependency tree, including transient dependencies. It does this by using the standard package metadata (the core metadata). A valid package is required for this to work (and yes, while maybe Poetry could special-case its own pyproject.toml format, that's an entire level of complexity and additional validations to support a niche use case that is not necessary).

What you ask for is well out of scope: you would have to import code that we define to modify sys.path to include other non-package directories and we would have to gain an entire new dependency resolution logic. In other words, blending more than one directory of non-package Python with packages (because you still have dependencies) is not something we intend to support.

You may be interested in #2270, which may provide something similar to what you ask for, if implemented.


This brings in all the boilerplate of packages when not needed

Also, to clarify: packages are not boilerplate. You want to re-use code across projects (where a 'project' is a pyproject.toml): that is a package. The burden of specifying enough metadata to build a valid package is not high.

@RiccardoRomagnoli
Copy link
Author

Thanks a lot for expanding the discussion, I now see the whole picture, definitely not an easy addition even though I think It is useful in some project/repo setting.

Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 17, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/feature Feature requests/implementations status/triage This issue needs to be triaged
Projects
None yet
Development

No branches or pull requests

4 participants