question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

PEP 517 isolation breaks test module with relative out-of-source dependency

See original GitHub issue

Environment

  • pip version: 19.0.2
  • Python version: 3.8.0a1
  • OS: Linux

Description In the PyO3 project, we have a test module nested inside the examples folder that needs to build against the version of pyo3 in the repository, which is located in ../.. relative to the source root, because it’s intended to test that version of PyO3. This is accomplished by specifying the path of the pyo3 root in Cargo.toml.

The problem is that when using PEP 517, the build root gets moved out of the source tree (fair), and we no longer have a reliable way to specify a relative out-of-source dependency.

Given that this is a pretty unusual requirement, I’m going to investigate various ways to work around this from within setup.py (maybe rewrite the Cargo.toml file with an absolute file path as part of an sdist build or write a custom PEP 517 backend), but I thought I’d bring it up as a potential incompatibility with PEP 517.

See pyo3/pyo3#362

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:13 (13 by maintainers)

github_iconTop GitHub Comments

1reaction
pfmoorecommented, May 11, 2020

@davidhewitt Thanks for the verification on this - we appreciate you taking the time to report back 🙂

Unfortunately, there have been a number of issues with the implementation of in-place builds (which are being tracked under #7555) which means that for now, we need to revert this change. As a result this issue will become a problem again, and we’ll therefore be reopening it. Longer-term, we hope to have a solution that addresses the issues that in-place builds solved, but without the impact on other workflows that the current solution had. Sorry for the disruption that this will cause.

(@pradyunsg - can you please include this information in the other issues covered by the in-place build changes, as we discussed?)

0reactions
sbidoulcommented, Jul 26, 2022

Now that #7555 has landed for good, I think this can be closed again. Holler if not.

Read more comments on GitHub >

github_iconTop Results From Across the Web

PEP-517 - definition of isolated build environments breaks ...
In my backend I want to use a tool that uses sysconfig to invoke its dependencies. In a normal virtual environment case to...
Read more >
Could not build wheels for _ which use PEP 517 and cannot ...
The easiest solution to deal with the error "Could not build wheels for ____ which use PEP 517 and cannot be installed directly"....
Read more >
Release 3.24.4 holger krekel and others - tox Documentation
this tox implements PEP-517 and PEP-518. This means that by default tox will build source distribution out of source.
Read more >
tox(1) — tox — Debian buster - Debian Manpages
To help with this tox implements PEP-517 and PEP-518. This means that by default tox will build source distribution out of source trees....
Read more >
EasyBuild v4.6.2 documentation (release 20221021.0)
use SYSTEM template constant in dependencies instead of True in framework tests (#4094). easyblocks. 2 new software-specific easyblock: CUDA compatibility ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found