Make `read-deps` `script` parameter accept directories

[bswck]

In the times when essential layout is yet being developed, I often find myself using uv to create virtual envs inside projects using it. I find it tedious to type in the command uv pip install $(python -m pip_run.read-deps __init__.py). I'd rather just do uv pip install $(python -m pip_run.read-deps .), which implies that for every directory d the read-deps script attempts to look for __requires__ inside d/__init__.py.

Other things to consider are whether __main__.py should be then taking precedence in such dirs or maybe whether we shouldn't combine all __requires__ lists from the whole directory. However, if I wanted to combine I'd simply extend the read-deps command to accept indefinite amount of script parameters and then invoke python -m pip_run.read-deps * (or other glob pattern necessary). And maybe if I wanted to get requirements for "module mode" (python -m), I'd rather expect pip-run to understand python -m pip_run.read-deps -m ..

If the script parameter accepts a dir, we could then default to . if no arg is provided, which beautifully simplifies my usage into uv pip install $(python -m pip_run.read-deps).

Is adding a simple logic for expanding a dir into <dir>/__init__.py a suitable feature?

[bswck]

I should essentially be using coh install for project installation, but nevertheless the issue still has some DX rationale :)

[jaraco]

Thanks for this report. It's well articulated what you're after and what solution you have in mind.

I've not been using read-deps much or run into this issue because I've been using a different workaround for installing a coherent package, namely copying system.toml to ./project.toml and then running pip or uv naturally.

I'm slightly reluctant to expand the scope of pip-run to overcome deficiencies in the coherent system, and I definitely don't want to build in assumptions that the coherent system is making (about where requirements are defined, etc).

If we allow the script to accept directories, we have to address several concerns, some of which you've already articulated:

• which file or files in the directory should be scanned for dependencies?
• if more than one file has dependencies, which should be considered?
• should subdirectories also be scanned?
• should non-python files be considered (e.g. requirements.txt)?

Is adding a simple logic for expanding a dir into <dir>/__init__.py a suitable feature?

I'm more inclined to consider a simple expansion of scope like simply expanding into __init__.py, especially because in Python, the directory and the __init__.py file represent the same entity (a Python package module) and that entity is symmetric with a specific Python file (also a Python module).

I also consider read-deps to be a second-tier feature of pip-run, not part of any critical behavior, so it's also okay to experiment with it and try things.

All that considered, I think yes should consider this feature (including the option for . to be the default "script"). We should probably rename script → target (where target means "path to a script or module").