Automatic scripting Error Recovery with SCons

[abitrolly]

Consider this snippet.

$ poetry run tox
The "poetry.dev-dependencies" section is deprecated and will be removed in a future version. Use "poetry.group.dev.dependencies" instead.
Creating virtualenv anitya-L2WRRFYm-py3.13 in /root/.cache/pypoetry/virtualenvs
Command not found: tox

The reason the command fails, is because tox is not installed, because poetry doesn't install stuff by default. But if poetry install stuff, it installs a whole lot of thing. The problem here is that tox makes isolated environments for testing, and installs the stuff again.

I am thinking that using SCons dependency graph it is possible to catch the latest error and match it against rules, and the invoke them. Like install tool tox in this case. Maybe somebody already did that?

[bdbaddog]

Doesn't really seem like SCons' domain here. this is a packaging dependency issue.

[abitrolly]

So why this error recovery tool based on SCons can not resolve packaging issues?

[mwichmann]

On November 27, 2025 2:18:07 AM MST, Anatoli Babenia ***@***.***> wrote: Consider this snippet. ```sh $ poetry run tox The "poetry.dev-dependencies" section is deprecated and will be removed in a future version. Use "poetry.group.dev.dependencies" instead. Creating virtualenv anitya-L2WRRFYm-py3.13 in /root/.cache/pypoetry/virtualenvs Command not found: tox ``` The reason the command fails, is because `tox` is not installed, because `poetry` doesn't install stuff by default. But if `poetry` install stuff, it installs a whole lot of thing. The problem here is that `tox` makes isolated environments for testing, and installs the stuff again. I am thinking that using SCons dependency graph it is possible to catch the latest error and match it against rules, and the invoke them. Like install tool `tox` in this case. Maybe somebody already did that? -- Reply to this email directly or view it on GitHub: #4792 You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

maybe if you explain a bit more what you're after? uv installs deps if the current directory doesn't look like a virtualenv, but uses the one it finds if it does. however: same problem, tox itself wants to create isolated envs, so lots of installing. there's a plugin called tox-uv that might help? tox is a little outdated in this regard. I'd echo Bill's comments that this isn't really up scons' alley as there are tools (possibly a bit deficient) that understand *this* kind of dependency management better. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[abitrolly]

It is an example. this kind of dependency is just a message from stderr. I don't know other tools that allow to process dependency graph.

[bdbaddog]

Unless you can propose something more concrete, it's probably not worth continuing this discussion.

Could SCons be used for this, maybe with a TON of work and effort for an "off brand" use.
Is it likely any SCons core developers will spend any time on this very unformed idea, not very likely.

[abitrolly]

Why should they? For the idea to happen, there should be a process control app that catches stderr and detects errors, looks them up from the database, and the executes chain of correction actions. The SCons role here is maintaining the chain between the error and action, so the error is a dynamic "artifact" that needs to be "built", and it appears dynamically, after each step/iteration.

I thought that some part of SCons engine could be reused for that. This way it is possible to create the build system that could try to build things using database of errors and actions without explicitly requiring writing SConstruct files.

[bdbaddog]

This is way out of scope for SCons. Closing discussion.