-
-
Notifications
You must be signed in to change notification settings - Fork 522
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
package = wheel not respected for individual env if prior env uses package = editable #3034
Comments
PR welcome 👍 |
@gaborbernat any pointers to where I might want to add debug statements/code changes? I'm not familiar with how configs are compiled for each env and how value of "package" is used. I can try to fix but to start I'd need some pointers if possible. Is there an option to print rendered config for each env to rule out config propagation issue? |
No idea where the issue might be. https://tox.wiki/en/latest/cli_interface.html#tox-config-(c) should help you, |
thanks, will debug further and provide a repro if possible |
This output looks ok, but it still installs editable for cli venv, as seen here:
So the bug is somewhere else, not in config. I will try to make a simple project to reproduce and share the repo. |
ok I found the issue. It's coming from the use of cachetools to wrap wheel build call. The arguments to editable and wheel build are identical, therefore a cached result is returned.
Since of_type is not an argument to this function, same wheel directory = same wheel. @gaborbernat should we add of_type to arguments of frontend build functions (even as a throwaway?) to avoid cache collision for different package types? I see cachetools has other key generation methods, such as "methodkey" and "typedkey", but we're using "hashkey" here, which I guess doesn't take function name into account (i.e. different frontend functions with same arguments = same cache result). In this particular case the key returned is a string "wheel" - both for editable and non-editable calls. Ah I think we use a custom key fuction which is defined here, that explains why key is just "wheel" - https://github.com/tox-dev/tox/blob/main/src/tox/tox_env/python/virtual_env/package/pyproject.py#L336 |
Indeed 🤔 you're suggestion seems reasonable so PR would be welcomed. |
@gaborbernat please have a look at the PR. Let me know if it makes sense. Also I could not find a unit test for Pep517VirtualEnvFrontend so I'm unsure if I need to write one from scratch. |
Yes we should write a new test 👍
…On Fri, Jun 16, 2023, 12:06 Dmitrii Sutiagin ***@***.***> wrote:
@gaborbernat <https://github.com/gaborbernat> please have a look at the
PR. Let me know if it makes sense. Also I could not find a unit test for
Pep517VirtualEnvFrontend so I'm unsure if I need to write one from scratch.
—
Reply to this email directly, view it on GitHub
<#3034 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFIQPRG2HPCOZHUVKW7A5DXLSVDJANCNFSM6AAAAAAZIPMGRM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Issue
Disclaimer - I'm using tox-pdm plugin but I don't think it matters as it doesn't use pdm to install the main package - it only handles dependencies.
Some parts of the config:
I have a few envs, and one of them overrides this with "package = wheel":
When I run tox, if there's another env before that (I use "depends" as you can see) which has no override and therefore uses editable package, then this env called "cli" also gets editable package installed, despite the override.
If I run the env separately with "tox -e cli" then I get expected behavior (not an editable wheel but a normal wheel), but if I run all envs I get incorrect behavior, cli env gets editable wheel installed.
Environment
Provide at least:
pip list
of the host Python wheretox
is installed:Output of running tox
Provide the output of
tox -rvv
:The text was updated successfully, but these errors were encountered: