> don't want to have virtual environments and learn what the difference between pip, poetry and uv is
Oh come on, it's easy:
Does the project have a setup.py? if so, first run several other commands before you can run it. python -m venv .venv && source .venv/bin/activate && pip install -e .
else does it have a requirements.txt? if so python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run ...
else does it have a pipfile? pipenv install and then prefix all commands with pipenv run ...
else does it have an environment.yml? if so conda env create -f environment.yml and then look inside the file and conda activate <environment_name>
else does it have a uv.ock? then uv sync (or uv pip install -e .) and then prefix commands with uv run.
If you've checked out a repo or unpacked a tarball without documentation, sure.
If you got it from PyPI or the documentation indicates you can do so, then you just use your tooling of choice.
Also, the pip+venv approach works fine with pyproject.toml, which was designed for interoperability. Poetry is oriented towards your own development, not working with someone else's project.
Speaking of which, a project that has a pipfile, environment.yml, uv.lock etc. and doesn't have pyproject.toml is not being seriously distributed. If this is something internal to your team, then you should already know what to do anyway.
It is not "no true scotsman" to point out that tons of projects are put on GitHub etc. without caring about whether others will actually be able to download and "install" and use the code locally, and that it's unreasonable to expect ecosystems to handle those cases by magic. To the extent that a Python ecosystem exists and people understand development within that ecosystem, the expectations for packaging are clear and documented and standard.
Acting as if these projects using whatever custom tool (and its associated config, by which the tool can be inferred), where that tool often isn't even advertised as an end-user package installer, are legitimate distributions is dishonest; and acting as if it reflects poorly on Python that this is possible, far more so. Nothing prevents anyone from creating a competitor to npm or Cargo etc.
Oh come on, it's easy:
Does the project have a setup.py? if so, first run several other commands before you can run it. python -m venv .venv && source .venv/bin/activate && pip install -e .
else does it have a requirements.txt? if so python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt
else does it have a pyproject.toml? if so poetry install and then prefix all commands with poetry run ...
else does it have a pipfile? pipenv install and then prefix all commands with pipenv run ...
else does it have an environment.yml? if so conda env create -f environment.yml and then look inside the file and conda activate <environment_name>
else does it have a uv.ock? then uv sync (or uv pip install -e .) and then prefix commands with uv run.