Support relative package includes using explicit destination paths

[RaitoBezarius]

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

[neersighted]

Migrating discussion from #5273 here -- this feature (specifically, the from/to version) is likely the best design for a variety of users:

• Users who consume a git repo and want to vendor it in to their package (they can combine this with a submodule)
• Users who want to share common code in a monorepo between packages and have it vendored
• Users who want to make use of relative path includes in their project without a monorepo -- currently, there are no semantics for Poetry to install that code into their environment properly

[adriangb]

I'd also add:

• Users who want to have namespace packages without having to create empty nested directories

[finswimmer]

I wonder how such a feature behaves for editable installations e.g. on poetry install? The only working solution I can see now is, that the data is copied from from to its destination given in to. What is expected here by users that requested that feature?

[MarximusMaximus]

I wonder how such a feature behaves for editable installations e.g. on poetry install? The only working solution I can see now is, that the data is copied from from to its destination given in to. What is expected here by users that requested that feature?

Might be able to use .pth files to do some clever symlink-like trickery? Perhaps by having the .pth look something like:

/path/to/package_name/src
package_name-includes

and have the package_name-includes folder be the root of the where 'to' is? (Note sure if naming it just package_name would work. Not sure if this is even a good idea, see "Alternatively" below.)
Note: .pth files may be python code (in a single line?) and not just a list of dirs, e.g. the gnarly stuff sphinx does:
sphinxcontrib_applehelp-1.0.2-py3.8-nspkg.pth:

import sys, types, os;has_mfs = sys.version_info > (3, 5);p = os.path.join(sys._getframe(1).f_locals['sitedir'], *('sphinxcontrib',));importlib = has_mfs and __import__('importlib.util');has_mfs and __import__('importlib.machinery');m = has_mfs and sys.modules.setdefault('sphinxcontrib', importlib.util.module_from_spec(importlib.machinery.PathFinder.find_spec('sphinxcontrib', [os.path.dirname(p)])));m = m or sys.modules.setdefault('sphinxcontrib', types.ModuleType('sphinxcontrib'));mp = (m or []) and m.__dict__.setdefault('__path__',[]);(p not in mp) and mp.append(p)

Alternatively
Alternatively, I'd expect it to do nothing as editable installs are very different from sdist and wheel installs, because as is, it doesn't appear to do anything with includes now.