I don't think so, though maybe I didn't explain myself correctly. You can link to a relative package wheel I think, but not to a package repo. So if you have a repo, with your main package in ./src, and you vendor or need a package from another subfolder (let's say ./vendored/freetype) , you can't actually do it in a way that won't break the moment you share your package. You can't put ./vendored/freetype in your requirements.txt, it just fails.
That means you either need to use pypi or do an extremely messy hack that involves adding the vendored package as a sub package to your main source, and then do some importlib black magic to make sure that everything uses said package.
In this scenario, reading between the lines, the vendor is not providing a public / published package but does provide the source as like a tarball?
I have yet to run into that particular case where the vendor didn't supply their own repo in favour of just providing the source directly. However I do use what are essentially vendor-supplied packages (distant teams in the org) and in those cases I just point at their GitLab/GitHub repo directly. Even for some components within my own team we do it this way.
It's more for either monorepos or in my case, to fix packages that have bugs but that I can't fix upstream.
So for me, in my specific case, the freetype-py repo has a rather big issue with Unicode paths (it will crash the app if the path is in Unicode).
There's a PR but it hasn't and probably won't get merged for dubious reasons.
The easy choice, the one that actually is the most viable, is to pull the repo with the patch applied, temporarily add it to my ./vendored folder and just ideally change the requirements.txt with no further changes (or need to create a new pypi package). But it's basically impossible since I just can't use relative paths like that.
Again it's rather niche but that's just one of the many problems I keep encountering. packaging anything with CUDA is still far worse, for example.
>The easy choice, the one that actually is the most viable, is to pull the repo with the patch applied, temporarily add it to my ./vendored folder and just ideally change the requirements.txt with no further changes (or need to create a new pypi package). But it's basically impossible since I just can't use relative paths like that.
You can use the repo's setup to build a wheel, then tell pip to install from that wheel directly (in requirements.txt, give the actual path/name of the wheel file instead of an abstract dependency name). You need a build frontend for this - `pip wheel` will work and that's more or less why it exists; but it's not really what Pip is designed for overall - https://build.pypa.io/en/stable/ is the vanilla offering.
It's in their example for how to use requirements.txt: https://pip.pypa.io/en/stable/reference/requirements-file-fo...
Maybe there's some concrete example you have in mind though?