Support relative `package` `include`s using explicit destination paths

• 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.

Feature Request

I am packaging a web application (https://github.com/RaitoBezarius/netbox) using Poetry for Nix/NixOS platforms (https://github.com/RaitoBezarius/nixexprs/blob/master/pkgs/python-packages/netbox/default.nix).

I am trying to include netbox/utilities/templates under the package utilities so that the site-packages contains utilities/templates, unfortunately, neither the documentation (on include / packages) neither https://github.com/python-poetry/poetry/issues/2015 seems to imply this is possible at all.

In the current case, adding netbox/utilities/templates/**/* to include array adds the data inside the "default" module (netbox) so that it looks like site-packages/netbox/utilities/templates instead of site-packages/utilities/templates.

This scenario is quite classical in a Django application, which bundles its own templates inside its own package.
In this case, the developers made an orthodox structure à la src/ and relies on the fact there is no top-level module (or namespace) to manage everything, so it makes the packaging unnatural to stuff that Poetry is used to process.
Supporting it would make it easier to package these legacy applications and would be an awesome addition.

I would have two proposals to enable this:

• Ensure that package data stays relative to the package in which it lies, e.g. look at the path to find the destination path, it requires minimal changes, and I am not sure as the default behavior is not really documented (?) that people do rely on it?
• Enable { from = "...", to = "..." } syntax in include to have perfect control, with sensible formats of to so it can be a bit flexible?

Thank you again for your awesome work, and, please let me know your thoughts on this.

Start by examining Poetry's handling of the include and packages configuration described in the issue and the linked documentation. Determine which destination-path behavior should be supported, then verify that a configured relative include can produce site-packages/utilities/templates rather than site-packages/netbox/utilities/templates.