fix: scripts/,docs/: With with virtual environments other than uv

[0cjs]

If uv is available, the scripts/* programs will still use it directly, but if not it assumes that the developer has set up a virtual environment in her own way and just runs pytest etc. directly. (If $VIRTUAL_ENV is not set, probably a virtual environment has not been set up and a warning will be printed, but things will still work if you have the necessary programs and libraries installed.)

Note that this does not check for $CONDA_DEFAULT_ENV or similar.

The documentation has also been updated to make this clear, and add the pip command that does the equivalent install into the current environment of what uv sets up.

• Pull request is based on the default branch (3.x at this time)
• Pull request includes tests for any new/updated operations/facts
• Pull request includes documentation for any new/updated operations/facts
• Tests pass (see scripts/dev-test.sh)
• Type checking & code style passes (see scripts/dev-lint.sh)
  - 2872 ruff errors and a mypy, but I believe that none of these are from this commit. Shellcheck passes.
• Pull request title follows the
  conventional commits format

[wowi42]

Hi, thanks for the contribution.

We are standardising on uv as the de facto project toolchain, so we would prefer not to add fallback paths for other virtual environment setups. I am going to close this PR. We appreciate you taking the time to open it.

[0cjs]

@wowi42 Well, I'm sure that the uv folks appreciate you promoting them by turning away developers that don't want to use it, even when it's completely unnecessary and allowing other virtualenvs takes such a minimal amount of code (not one extra line in the script files: just the new common.bash), but you do you. This has very much put me off contributing to this project.

[wowi42]

@0cjs We understand the frustration, and we genuinely appreciate the time you put into the PR. The decision to standardize on uv is not about promoting a tool; it is about keeping the project toolchain maintainable. Supporting multiple virtual environment workflows means more paths to test, document, and debug, which spreads maintainer attention thinner.

That said, this choice is not a reflection on the quality of your work. We are sorry this experience has put you off contributing, and we would still welcome contributions in areas that do not touch the toolchain. If you would like to discuss the uv decision further, feel free to open a discussion rather than continuing here.

[0cjs]

You could very well say you simply don't support non-UV workflows without insisting in your code that they cannot be used. If you need the system to print documentation about this, and even require an explicit opt-in to use a non-UV workflow, I can do that pretty easily. (And I'm also willing to help support non-UV workflows, though honestly I don't see the issue with, "If you're not using UV, and you can't work it out yourself, just switch to UV." As opposed to, "If you used something other than UV and it worked, please go away anyway.") I am explicitly trying to do this in a way that you don't have any extra work, but gain the benefit of my work. So if anything can convince you of that, let me know what it is.

If not, let me leave you with this: what you really need to do, rather than rail against non-UV users, is start fixing stuff like the 2800-plus errors that your test scripts show that your CI doesn't. And the errors I found while working on this PR that your CI shows that your test scripts don't, wasting the time of everybody who has to go through several loops of "submit PR and wait for CI" rather than just seeing the error right there immediately. I'm willing to help with that (with expertise; build systems have been a big part of my daily work for decades), but if your price is, "I don't like you if you use tools that work but are not my preferred tools" you're not going to get that help. Think on it.

...we would still welcome contributions in areas that do not touch the toolchain.

Yeah, but you can't get them if I don't touch the toolchain because I will not run uv to create my virtual environments. The whole point of what I did was not to touch the toolchain, but to get the things your toolchain blocks out of the way so I can do more useful work. Again, think on it. You've seen the help I've provided so far: is allowing (but not supporting) other toolchain usage really going to get you more than that?

I'm not totally clear on what you mean by "open a discussion," but feel free to put your reply (if you want to bother) wherever you feel is best and I will follow that lead.

[wowi42]

@0cjs,

I want to address the substance, but first: please watch your tone. We do not know each other, and assumptions about our motives or character do not help this discussion.

You are right that we could technically allow non-uv workflows without officially supporting them. The concern on our side is not hostility toward other tools; it is that every allowed path becomes a path people report bugs against, and that maintenance cost lands on us. "Allow but not support" rarely stays unsupported in practice. If we merge code we are not sure you will maintain long-term, we are left supporting it when issues appear. That is why we are keeping the toolchain uniform.

That said, your point about test/CI drift is worth looking at. If there really are failures that local scripts and CI disagree on, please open a separate issue with specifics: which commands, which failures, and which CI jobs differ. We will investigate.

If you want to continue the toolchain discussion, please use https://github.com/pyinfra-dev/pyinfra/discussions. We are not asking you to use uv personally; we are saying that contributions changing the toolchain need to fit the project's direction. Contributions that fix tests, CI, or bugs are welcome and do not require that.