Replies: 1 comment
-
Hm. Now that I've asked the question, it occurred to me that the answer may very well be "what you want is simply not possible if the list of dependencies is dynamically generated - Tox cannot know what the build system will do without, well, invoking the build system itself". Argh. Still, is there a way to do it at least for the non-dynamically-generated-dependencies case? :) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
First of all, thanks a lot for writing and maintaining Tox!
Now, this may be something of a "so don't do that!" type of question, or it may be that I'm missing something obvious, but here goes. In many of my Python projects (that I think nobody but me has ever installed, but oh well :)) I've told the PEP517 build system to look for a
requirements/install.txt
file where I list the project dependencies. This allows me to, among other things, install them in test environments that examine the source tree and want to look deeper into some of the imported packages; the classic example is a type checker likemypy
.Recently I've been playing with declaring everything in the
pyproject.toml
file, using PEP735 dependency groups to define the dependencies for the test environments. With judicious use ofinclude-group
, this works just fine, with a single exception: now I'm not sure how to tell Tox that I need a test environment in which the project dependencies are installed (somypy
can look into them), but the project itself is not (the build may not even succeed at that point, I still want the type checker to run on the partial sources).So... is there a way to do what I want with Tox, or should I rethink my approach? (a completely valid option!)
Thanks in advance for your time, and keep up the great work!
Beta Was this translation helpful? Give feedback.
All reactions