Add pylock parser and validator #13369
Conversation
dbeaaab to
73f0c6a
Compare
|
Ok, this is in good shape, now. Wondering if |
48627a9 to
7278c95
Compare
... or maybe as part of the |
Indeed, if we move out the toml export function (which I just did), it makes sense. |
e5f7859 to
6ae54d3
Compare
|
Ok, I went all the way to reading all the fields from the spec, and added a round trip test with the example from PEP 751. |
7e6d977 to
643f66f
Compare
|
Meh, kw_only dataclasses are cool, but do not exist in Python 3.9. |
c3c068a to
51ddd3a
Compare
|
So I hand-knitted Note, that all this is because I want to preserve the recommended field ordering from the spec for serialization, and there are required fields without default values that come after optional fields. Additionally keyword-only constructors make for a cleaner and more robust API. |
|
|
| else: | ||
| output_file_path = Path(options.output_file) | ||
| if not is_valid_pylock_file_name(output_file_path): | ||
| if not is_valid_pylock_path(output_file_path): | ||
| logger.warning( | ||
| "%s is not a valid lock file name.", | ||
| output_file_path, | ||
| ) | ||
| base_dir = output_file_path.parent |
There was a problem hiding this comment.
I’m thinking, in many situations it might not actually be desirable to use a relative path. Not sure if there’s a good way to tell which way the user wants each package to be. Since outputting to stdout always generates an absolute path, maybe it’s less confusing if absolute path is the default when you output to a file too, and you need to somehow tell pip to use a relative path explicitly. Something similar to how we have --only-binary for install? I don’t know.
There was a problem hiding this comment.
I'm not sure either. I'd say relative paths below the pylock.toml location is a good default. And it gives a nice result for the common pip lock -e ..
Anyway, I'm going to remove this change from this PR and handle that separately.
There was a problem hiding this comment.
I feel as though when you generate a pylock file, it makes sense for the paths to be relative to the location of the file. But when you generate to stdout (which has no location), it makes sense for paths to be absolute. As you say, though, maybe we don't want relative paths that go up in the filesystem hierarchy.
I'd go with:
- When writing to stdout, absolute.
- When writing to pylock, if the target is alongside (or below) the lockfile, then relative, ohterwise absolute.
But it's debatable enough that I think doing it as a separate PR is sensible.
Move conversion of install requirements to pylock to utils namespace, so model.pylock has no pip dependencies.
The context provided by the field name is sufficient, so we can have the same error message for all package sources
We can remove them when we drop support for Python 3.9
Better start abstract and make it more concrete later if/when use cases arises.
…ency-groups The specs says these fields are optional with default = []. But it also says "Tools SHOULD explicitly set this key to an empty array to signal that the inputs used to generate the lock file had no dependency groups (e.g. a pyproject.toml file had no [dependency-groups] table), signalling that the lock file is, in effect, multi-use even if it only looks to be single-use.", implying that the distinction between absent and empty is meaningful.
|
I proposed this to packaging in pypa/packaging#900 So marking as draft here until there is feedback there. |
Towards #13334
TODO