pyproject.toml configuration error for dash-separated module name

[jaraco]

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.

ValueError: invalid pyproject.toml config: `tool.setuptools.py-modules[0]`.
configuration error: `tool.setuptools.py-modules[0]` must be python-module-name
Backend: run command get_requires_for_build_editable with args {'config_settings': None}
configuration error: `tool.setuptools.py-modules[0]` must be python-module-name
GIVEN VALUE:
    "pip-run"

OFFENDING RULE: 'format'

DEFINITION:
    {
        "type": "string",
        "format": "python-module-name"
    }

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?

[abravalheri]

Yes that is possible.

Currently the definition comes from:

https://github.com/abravalheri/validate-pyproject/blob/v0.16/src/validate_pyproject/plugins/setuptools.schema.json#L158

and

https://github.com/abravalheri/validate-pyproject/blob/v0.16/src/validate_pyproject/formats.py#L243-L244.

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?

[jaraco]

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.