pip install with relative paths in pyproject.toml doesn't seem to work

[finete]

How do I specify relative paths that pip can use in pyproject.toml?

poetry successfully installs them, however pip fails with the following error:

File "/tmp/pip-build-env-ck09aiax/overlay/lib/python3.7/site-packages/poetry/core/packages/directory_dependency.py", line 36, in __init__
        raise ValueError("Directory {} does not exist".format(self._path))
    ValueError: Directory ../lib_foo does not exist

---

Example

I have the following repository structure

.
├── lib_foo
│   ├── lib_foo
│   │   └── __init__.py
│   └── pyproject.toml
└── main_app
    ├── main_app
    │   └── __init__.py
    └── pyproject.toml

main_app is dependent upon lib_foo, its dependecies looks like this:

./main_app/pyproject.toml

[tool.poetry.dependencies]
python = "^3.7"
lib-foo = { path = "../lib_foo" }  # also tried  path = "../lib_foo/"

when doing:

./main_app$ poetry install  # runs successfully 
./main_app$ python -m pip install ../lib_foo/ # runs successfully
./main_app$ python -m pip install .  # fails with the error mentioned above 
./main_app$ python -m pip --version
pip 20.1.1 from ./main_app/my_venv/lib/python3.7/site-packages/pip (python 3.7)

---

I am using poetry when developing a project however when deploying them I want to only use pip

[pfmoore]

You need to build a wheel to deploy. If you're deploying with sources, then you'll need the build tool (poetry) at deploy time.

How poetry turns a relative path in the [tool.poetry.dependencies] section of pyproject.toml (which is a poetry-specific section) into a valid dependency for a wheel is something to ask on a poetry support forum, if it doesn't work as you expect.

[finete]

@pfmoore Isn't the following a bit inconsistent?

---

./main_app/requirements.txt

../lib_foo/; python_version >= "3.7" and python_version < "4.0"

python -m pip install -r requirements.txt # works fine

---

./main_app/pyproject.toml

[tool.poetry.dependencies]
python = "^3.7"
python-dateutil = "^2.8.1"

python -m pip install . # works fine

---

./main_app/pyproject.toml

[tool.poetry.dependencies]
python = "^3.7"
lib-foo = { path = "../lib_foo/" }

python -m pip install . # fails

[uranusjr]

Consequence of #7555. May be resolved with #9091.

[finete]

@pfmoore Note that even when I build the package it fails:
./main_app$ python -m pip install dist/main_app-0.1.0.tar.gz # fails with the pervious error

./main_app$ python -m pip install dist/main_app-0.1.0-py3-none-any.whl # fails with the following error:

  File "/home/ubuntu/Code/tinkering/pip_toml_try/main_app/my_venv/lib/python3.7/site-packages/pip/_vendor/pkg_resources/__init__.py", line 3103, in __init__
    raise RequirementParseError(str(e))
pip._vendor.pkg_resources.RequirementParseError: Invalid URL: ../lib_foo

---

Does that mean that currently I need to use poetry install in deployment when specifying a relative paths in pyproject.toml?
Or am I building incorrectly ?

[uranusjr]

You should not be able to build the package, since it is not allowed to have dependencies specified as relative paths in package metadata. PEP 508 only allows version specifiers and URL (which only allows absolute paths even if you use file://). Poetry should fix this.

[finete]

@uranusjr Thanks you for the reference, I will rephrase my issue.
this issue is not about building distributions with relative paths, it's about being able to use pip install on a pyproject.toml file that contains relative paths.
Not unlike with a requirements.txt file.

[pfmoore]

pyproject.toml is not a requirements file, though.

The section

[tool.poetry.dependencies]
python = "^3.7"
lib-foo = { path = "../lib_foo" }  # also tried  path = "../lib_foo/"

is poetry-specific, but I presume that it ultimately gets translated into Requires-Dist metadata, which is specified here, which in turn references PEP 508. And PEP 508 does not allow relative paths in a dependency specification.

To be standards-compliant, Poetry shouldn't allow this as well, but this is something you'd need to take up with the Poetry project - they control the tool.poetry.dependencies namespace, and as long as they don't put invalid data into a standard metadata file, they can do what they like with it.