poetry build error with path develop dependency

[kapilt]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: OS X Catalina (10.15.2)
• Poetry version: 1.0.3
• Link of a Gist with the contents of your pyproject.toml file: https://gist.github.com/kapilt/5b3808ad3e54f5ae83147d259b1f0cef

Issue

Running poetry build with a directory develop dependency results in multiple errors. the initial traceback (with -vvv) is in the gist, and results from a relative path usage when using a directory dependency, simply adding a self._full_path = (self._base / self._path).resolve() to line 33 of directory_dependency works past that. with that fix the second error occurs when trying to build the wheel (post successful sdist build),

 [ValueError]
Directory /private/var/folders/m0/9m4c62yx3sd12290vsfcc14m0000gn/T does not seem to be a Python package

Traceback (most recent call last):
  File "/Users/kapilt/.poetry/lib/poetry/_vendor/py3.8/clikit/console_application.py", line 131, in run
    status_code = command.handle(parsed_args, io)
  File "/Users/kapilt/.poetry/lib/poetry/_vendor/py3.8/clikit/api/command/command.py", line 120, in handle
    status_code = self._do_handle(args, io)
  File "/Users/kapilt/.poetry/lib/poetry/_vendor/py3.8/clikit/api/command/command.py", line 171, in _do_handle
    return getattr(handler, handler_method)(args, io, self)
  File "/Users/kapilt/.poetry/lib/poetry/_vendor/py3.8/cleo/commands/command.py", line 92, in wrap_handle
    return self.handle()
  File "/Users/kapilt/.poetry/lib/poetry/console/commands/build.py", line 30, in handle
    builder.build(fmt)
  File "/Users/kapilt/.poetry/lib/poetry/masonry/builder.py", line 21, in build
    return builder.build()
  File "/Users/kapilt/.poetry/lib/poetry/masonry/builders/complete.py", line 55, in build
    Factory().create_poetry(tmpdir),
  File "/Users/kapilt/.poetry/lib/poetry/factory.py", line 99, in create_poetry
    package.add_dependency(name, constraint)
  File "/Users/kapilt/.poetry/lib/poetry/packages/package.py", line 326, in add_dependency
    dependency = DirectoryDependency(
  File "/Users/kapilt/.poetry/lib/poetry/packages/directory_dependency.py", line 51, in __init__
    raise ValueError(

Its a little unclear what should happen here, the directory dep is to help model packaging for a dev environment for a mono repo with several packages. for publishing/building it would be nice to just resolve the dependency to its name and version and insert that metadata into the wheel egg.

[kapilt]

still noodling on how to model this workflow well with poetry (public packages interdependent, single monoreepo) option here is to add a version/constraint key to a directory path dep in pyproject.toml, so that on build it can be referenced by the version in PKG-INFO, else it will end up with a naked package name in the sdist/wheel.

[kapilt]

with #2047, poetry build --format=sdist and poetry build --format=wheel both work, with caveat, that the PKG-INFO dep is just the package name.

however poetry build still fails with the initially reported issue traceback.

[aeroaks]

poetry build --format=wheel works for me as well.

[adamal]

Given this comment, I'd like to point to the usefulness of having the source (or "compiled" package) included in the build output (as opposed to just the package name).

This allows for using Poetry to build distributable/deployable packages containing local packages that may be shared between projects, without needing to deploy the dependencies to a remote package repo, reducing complexity of the build system.

Analogously, in C# it's trivial to depend on other local projects, whose resulting .dll will be included in the referencing solution's build output.

[misterjoa]

Hello everyone,
we are also facing this as we have a monorepo and want to be able to build dev packages locally and use defined versions of packages in prod.
Seems related to #1168

[github-actions]

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.