ENH: add support for dynamic dependencies computation #319
Conversation
dnicolodi
force-pushed
the
dynamic-dependencies
branch
2 times, most recently
from
7c02c7f to
3617eba
Compare
There was a problem hiding this comment.
This approach is not enough. You need to be able to match versions with more than 3 parts on the release field.
Let's discuss this on the issue first. I had written a reply to you and Ralf, but I've been trying to put all my thoughts down regarding this in a document, so I haven't submitted it yet. Some more discussion happened, so I'll probably have to rewrite my reply, but please just wait for my reply there.
|
I just wanted to experiment with how this would look like in practice. Working on this made me realize that I didn't completely understand the problem. Matching version with more than three components is an easy fix. Added. You can use |
dnicolodi
force-pushed
the
dynamic-dependencies
branch
from
3617eba to
fb1fde9
Compare
dnicolodi
force-pushed
the
dynamic-dependencies
branch
13 times, most recently
from
f5c992d to
4af1454
Compare
dnicolodi
force-pushed
the
dynamic-dependencies
branch
4 times, most recently
from
824217e to
57d4e49
Compare
|
I converted the PR to draft while we wait for a resolution in #29, so that the state of PR log is easier to understand. @dnicolodi I hope that is okay. Once we get a decision on the issue, we can go ahead with a proper review and merge of this PR :) |
To support "dependencies" as a dynamic filed in pyproject.toml and implement build time dependencies pins we need to rewrite this part of the metadata in the wheel builder. Move the RFC 822 serialization of the metadata closer to where it is written to the wheel archive.
dnicolodi
force-pushed
the
dynamic-dependencies
branch
2 times, most recently
from
f0cd7a6 to
ef3d287
Compare
Move to stand-alone function for clarity and to enable unit testing.
When "dependencies" is specified as a dynamic field in the "[project]" section in pyproject.toml, the dependencies reported for the sdist are copied from the "dependencies" field in the "[tool.meson-python]" section. More importantly, the dependencies reported for the wheels are computed combining this field and the "build-time-pins" field in the same section completed with the build time version information. The "dependencies" and "build-time-pins" fields in the "[tool.meson-python]" section accept the standard metadata dependencies syntax as specified in PEP 440. The "build-time-pins" field cannot contain markers or extras but it is expanded as a format string where the 'v' variable is bound to the version of the package to which the dependency requirements applies present at the time of the build parsed as a packaging.version.Version object.
It is not possible to define a universally useful semantic for build-time pins involving pre-releases. Do not generate them.
dnicolodi
force-pushed
the
dynamic-dependencies
branch
from
ef3d287 to
58606b9
Compare
2 participants
When
dependenciesis specified as a dynamic field in the[project]section in pyproject.toml, the dependencies reported for the sdist are copied from thedependenciesfield in the[tool.meson-python]section. More importantly, the dependencies reported for the wheels are computed combining this field and the "build-time-pins" field in the same section completed with the build time version information.The
dependenciesandbuild-time-pinsfields in the[tool.meson-python]section accept the standard metadatadependencies syntax as specified in PEP 440. The
build-time-pinsfield cannot contain markers or extras but it is expanded as a format string where thevvariable is bound to the version of the package to which the dependency requirements applies present at the time of the build parsed as a packaging.version.Version object.This is based on #304 to incorporate the metadata handling simplification introduced there.
This ass a dependency on
importlib_metatadafor Python 3.7. In principle it could be made conditional to the use ofbuild-time-pinsbut I don't think it is worth the trouble. It also adds a dependency onpackaging, but it is already a transitive dependency of meson-python via thepyproject_metadatadependency.