Unfortunately, I cannot promise that we will replace Poetry’s lock file if this and that is added. I can only promise that we will try/evaluate. However, even this will take some time (at least months, I assume).
In the current state, we probably would just use it as an export format - and to be honest that is perfectly fine for us. (Less work, less risk.). [1]
Considering the open issues:
I’m also leaning against it. Optional is fine.
Currently, we only record the index URL (or no URL at all for the default PyPI) and search the package in the index at install time so I think we are neutral on this.
I would not drop hashes but wonder if file sizes are necessary. Is it always possible to get file sizes without downloading the file? (It would be a pity if we had to download all wheels during locking just to get file sizes even though the hashes are provided by the index.)
I’m also leaning against it.
As already mentioned, this is fine for us.
Neutral.
I’m supporting the idea.
I am against it if the format is to replace tool-specific lock files. In my opinion, dropping the [tool] table is a clear step from “might replace tool specific lock files” to “just an export format”. I do not think we would try to replace our lock file without a [tool] table. (As already mentioned this outcome would also be perfectly fine for us.)
I am against it if the format is to replace tool-specific lock files. If we want to replace our tool specific lock file, I do not think it will always be possible to make the [tool] table disposable. Over time, when extending the format the [tool] table might become less relevant though.
I think I do not understand exactly what that means.
We would probably put this into the [tool] section since it is just required for convenience.
Currently, we calculate this information (if requested) from dependencies.
Although Poetry prefers to lock a single version of a package if it satisfies all constraints, Poetry does already support Boolean logic for extra selection.
I think that is exactly what Poetry is doing. [2] If we wanted to replace our lock file, we would use extra in packages.marker.
This is required if we want to replace our lock file. We could put it into the tool section so that other installers will always install all groups. On the other hand, this only works as long as there are no conflicting groups. [3]
To put it in a nutshell, we might try to replace our lock file and put relevant information in the tool section (if this section is not dropped). Support for dependency groups is crucial for us. We might put this information in the tool section. Further, the way we cope with extras might be incompatible with other installers. We would probably also only accept lock files created by Poetry itself (resp. containing the relevant tool.poetry sections) as input - at least in the beginning. Alternatively, we just use it as an export format, which avoids the controversial topics “dependency groups” and “extras”.
Alternatively, we might even try to use it as lock file with crucial information in the tool section. For details see below. ↩︎
see Dependency specification | Documentation | Poetry - Python dependency management and packaging made easy and markers: add special handling for `extra` by radoering · Pull Request #636 · python-poetry/poetry-core · GitHub for details ↩︎
Currently, Poetry does not support conflicting groups. ↩︎