Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"poetry build" with relative path dependency in pyproject.toml raises ValueError #266

Closed
RaptDept opened this issue Jun 28, 2018 · 14 comments
Labels
area/build-system Related to PEP 517 packaging (see poetry-core) kind/feature Feature requests/implementations

Comments

@RaptDept
Copy link
Contributor

RaptDept commented Jun 28, 2018

  • OS version and name: Windows 10 Pro, version 1803, build 17134.112
  • Poetry version: 0.11.0-alpha.4
  • Link of a Gist with the contents of your pyproject.toml file: pyproject.toml

Issue

Note: I:\Projects\bar-project exists, while poetry add bar-project --path ../bar-project and poetry install bar-project definitely work.

PS I:\Projects\foo-project> poetry build -vvv
Using virtualenv: I:\Projects\foo-project\.venv
Building foo-project (0.1.0)
 - Building sdist
 - Adding: rootnamespace\myapp\__init__.py
 - Adding: rootnamespace\myapp\__main__.py
 - Adding: rootnamespace\myapp\cli\__init__.py
 - Adding: rootnamespace\myapp\dependencies\__init__.py
 - Adding: rootnamespace\myapp\dependencies\c2p.py
 - Adding: rootnamespace\myapp\dependencies\constants.py
 - Adding: rootnamespace\myapp\dependencies\p2c.py
 - Adding: pyproject.toml
 - Built foo-project-0.1.0.tar.gz

[ValueError]
Directory ..\bar-project does not exist

Exception trace:
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\_vendor\cleo\application.py in run() at line 94
   status_code = self.do_run(input_, output_)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\console\application.py in do_run() at line 87
   return super(Application, self).do_run(i, o)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\_vendor\cleo\application.py in do_run() at line 197
   status_code = command.run(input_, output_)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\console\commands\command.py in run() at line 72
   return super(BaseCommand, self).run(i, o)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\_vendor\cleo\commands\base_command.py in run() at line 146
   status_code = self.execute(input_, output_)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\_vendor\cleo\commands\command.py in execute() at line 107
   return self.handle()
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\console\commands\build.py in handle() at line 27
   builder.build(fmt)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\masonry\builder.py in build() at line 21
   return builder.build()
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\masonry\builders\complete.py in build() at line 25
   poetry.poetry.Poetry.create(tmpdir),
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\poetry.py in create() at line 127
   package.add_dependency(name, constraint)
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\packages\package.py in add_dependency() at line 269
   develop=constraint.get("develop", False),
 C:\Users\Win10\AppData\Roaming\Python\Python36\site-packages\poetry\packages\directory_dependency.py in __init__() at line 48
   raise ValueError("Directory {} does not exist".format(self._path))

build [-f|--format FORMAT]

Changing the dependency path to an absolute path in pyproject.toml as below makes poetry build work without any errors.

...
[tool.poetry.dependencies]
python = "^3.6"
bar-project = {path = "I:/Projects/bar-project"}
toml = "^0.9.4"
pyyaml = "^4.1"
...
PS I:\Projects\foo-project> poetry build -vvv
Using virtualenv: I:\Projects\foo-project\.venv
Building playerdotme-pydevtools (0.1.0)
 - Building sdist
 - Adding: rootnamespace\myapp\__init__.py
 - Adding: rootnamespace\myapp\__main__.py
 - Adding: rootnamespace\myapp\cli\__init__.py
 - Adding: rootnamespace\myapp\dependencies\__init__.py
 - Adding: rootnamespace\myapp\dependencies\c2p.py
 - Adding: rootnamespace\myapp\dependencies\constants.py
 - Adding: rootnamespace\myapp\dependencies\p2c.py
 - Adding: pyproject.toml
 - Built foo-project-0.1.0.tar.gz

 - Building wheel
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\__init__.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\__main__.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\cli\__init__.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\dependencies\__init__.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\dependencies\c2p.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\dependencies\constants.py
 - Adding: C:\Users\Win10\AppData\Local\Temp\tmp1nt0r_e4\foo-project-0.1.0\rootnamespace\myapp\dependencies\p2c.py
 - Built foo_project-0.1.0-py3-none-any.whl
@sdispater
Copy link
Member

I am not sure why you would want to build a package with local path dependencies. The build command is here to build distributions that can be published or distributed. But if you have a local dependency it won't be included in the final distribution and anyone installing your package will be missing this dependency.

Local path dependencies should only be used for applications, which do not require build, or in the dev-dependencies section which is not included in the final distributions. 

@RaptDept
Copy link
Contributor Author

I see what you mean, and after some tinkering with poetry to deploy an application that has local (unpublished) dependencies, I've found that I don't need build for my use case like you mentioned. However, I thought it'd be worth mentioning the inconsistent behavior since build works when using absolute paths.

@sdispater
Copy link
Member

I agree. I think it would be best to make build raise an error when local path dependencies are specified in the pyproject.toml like it does for git dependencies.

@cauebs
Copy link
Contributor

cauebs commented Jul 4, 2018

@sdispater I just tried and it builds fine with git dependencies. I also found nothing in the code related to that. Am I missing something? :/

@sdispater
Copy link
Member

@cauebs You are right. I was confusing it with something else. But this is definitely something we should add to the build command.

@sdispater sdispater added area/build-system Related to PEP 517 packaging (see poetry-core) kind/feature Feature requests/implementations labels Jul 25, 2018
@stale
Copy link

stale bot commented Nov 13, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Nov 13, 2019
@stale
Copy link

stale bot commented Nov 20, 2019

Closing this issue automatically because it has not had any activity since it has been marked as stale. If you think it is still relevant and should be addressed, feel free to open a new one.

@stale stale bot closed this as completed Nov 20, 2019
@clintmod
Copy link

I just ran in to this today… but I am seeing it in poetry 1.0.0 with a relative path in my dev dependencies. Different bug?
I don't think the build command should care about dev dependencies.

@kevinastone
Copy link

I ran into this today. I'd expect poetry build to allow building packages that have relative path dependencies since it has no effect on the end sdist/wheel. I'm trying to setup a monorepo with a collection of interdependent packages that I'd like to develop together, but publish independently.

This error is caused by unpacking the sdist into a temp directory which no longer has the relative path. This tmpdir is causing all relative paths to be rooted against the tempdir instead of the project root:
https://github.com/kevinastone/poetry/blob/754dbf80dc022b89974288cff10b40ab2f1c2697/poetry/masonry/builders/complete.py#L53-L55

kevinastone added a commit to kevinastone/poetry that referenced this issue Mar 2, 2020
Building wheels unpacks the sdist which includes a copy of the
`pyproject.toml`.  If dependencies are delcared using relative paths
(such as `mymodule = { path = '../mymodule' }`), these relative paths
are not available from the temporary directory created to unpack and
build the wheel.  This fix retains the original path to the project for
those relative dependencies.

Fixes python-poetry#266.
kevinastone added a commit to kevinastone/poetry that referenced this issue Mar 2, 2020
Building wheels unpacks the sdist which includes a copy of the
`pyproject.toml`.  If dependencies are delcared using relative paths
(such as `mymodule = { path = '../mymodule' }`), these relative paths
are not available from the temporary directory created to unpack and
build the wheel.  This fix retains the original path to the project for
those relative dependencies.

Fixes python-poetry#266.
@BrainLogic
Copy link

Hi @sdispater,
Do you consider to fix/improve this part of the functionality?

According to the doc https://python-poetry.org/docs/versions/#path-dependencies
Users expect that Poetry has the ability to work with dependencies located in a local directory or file. However, it does not work, even for dev-dependencies.
If a relative path-dependency is specified then poetry build won't work. The root cause was described above.

And if you suggest to not use local path dependencies, then could you please explain here/in doc for what porpuses path-dependencies feature was implemented? It is confusing to figure out the use of path-dependencies by the current documentation and face such issues.

Thanks.

@adamal
Copy link

adamal commented May 27, 2020

Should this issue be reopened?
It was closed automatically due to inactivity but has recently seen new interest.

The way I was expecting poetry build to work when including a local dependency, say ../shared, would be to include /shared and its dependencies in the output.

A use case for this is to have local packages that are not necessarily published but could be included in several related projects.

Either way, it would be good to have this behaviour documented in more detail at https://python-poetry.org/docs/versions/#path-dependencies

@finswimmer
Copy link
Member

Hello,

the ValueError arises of poetry tries to create build sdist and wheel in one run, because the wheel get's created of the unpacked sdist. The workaround is to use -f sdist and -f wheel seperatly. The different behavior is a bug, that we should fix.

However, with this workaround the path will not end up in the sdist or wheel, only the package name will be included. In my opinion this is the correct behavior, because as @sdispater says path dependencies are quite useless if you want to share your package, but make sense during development.

I will keep this issue close in favor of #2046. Please go on there for further discussion.

fin swimmer

@william-richard
Copy link

I think I'm having a similar or related issue #4739

Copy link

github-actions bot commented Mar 2, 2024

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 2, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/build-system Related to PEP 517 packaging (see poetry-core) kind/feature Feature requests/implementations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants