Closed tiran closed 2 weeks ago
I think that method is designed with the idea that it returns data, and something else writes it to the wheel. @shubhbapna can confirm.
Yes, currently it is designed to only return data which we will write into the fromager-build-settings
file. Will giving access to dist_info_dir
to the plugin cause the following issues:
fromager-build-settings
file. We can lose any data that fromager put theirfromager-build-backend-requirements.txt
with their custom data but that will be overwritten by fromager and the user will lose that dataWe give plugins write information to lots of other aspects of the build, so if they choose to do something that undoes fromager's work I think I'd just say that's up to them and they get what they get as a result. We could also deal with that by writing the core metadata after the plugin is called, so we would be overwriting any files they create with our names.
The bigger question for me is, do we want plugins to write files or do we want them to give us data and let us write files? Letting them write files is more flexible, since the plugin can create whatever types of files it wants/needs. Having them return data to us means we control the format and location of the data, which is more consistent.
I prefer to have control over the format and location of data:
build-sequence
will propogate to bootstrap
which will make things difficult to debugI don't have any intent to write any files from add_extra_metadata_to_wheels
. I would like to give the plugin method access to the unpacked files, so it can read and analyze the content of the wheel file.
Make sense we can add it
The
add_extra_metadata_to_wheels
override method should have access to the unpacked wheel files. Let's run the method after unpacking the wheel and pass thedist_info_dir
to the method, too. The caller can assume that the parent directory ofdist_info_dir
is the root directory of the unpacked wheel.