Open jaraco opened 3 weeks ago
Yes that is possible.
Currently the definition comes from:
and
I will probably select or define a new format for this (should it be any kind of string or merely accept -
as a replacement for _
?).
Is this something we also want to apply to packages
?
Is this something we also want to apply to
packages
?
I thought about this a bit and i do think it makes sense to apply the same to packages, for symmetry and also because Python supports it:
@ mkdir foo-bar
@ touch foo-bar/__main__.py
@ py -m foo-bar
@ py -m foo-bar && echo done
done
I will probably select or define a new format for this (should it be any kind of string or merely accept
-
as a replacement for_
?).
I have confirmed that Python also supports runpy
invocation of other paths, including those with spaces and unicode charactors. Presumably one could supply any string that's a valid path name.
If you want to be extremely permissive, it sounds as if only disallowing /
, \
, :
, and \x00
(NUL) would be most lenient while still being consistent across platforms. Of course, you'd have to exclude the presence of .
also, as that's a Python module separator. I'd be slightly inclined to only require it to be a string of length >= 1 with no .
, and let the operating system enforce any invalid values by users.
My instinct, though, is to limit to just -
for now.
The pip-run project defines a py-module that has a dash in the name. It does so intentionally in order to make it possible to type
python -m pip-run
without having to enter any chorded characters (-
is roughly 1/3 as expensive as_
).After converting the config to pyproject.toml, however, this value is rejected by policy.
I can understand why "python-module-name" seemed like a good reasonableness check, but it turns out to be backward incompatible and unnecessarily constraining against a use-case like above.
Can we back out this change and make it lenient as it was with setup.cfg?