Support readme files #58
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
diazona
added
enhancement
|
This caused a failure in local testing lol $ python3.6
Python 3.6.15 (default, Jan 3 2022, 03:00:17)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import mimetypes
>>> mimetypes.guess_extension("text/plain")
'.bat'🤯 🤦 🤦 Apparently it affects Python <3.8 |
|
The readme field in pyproject.toml is populated from long_description and long_description_content_type (if present) in the setuptools configuration. This one is a little complicated though, because calling Distribution.get_long_description() will just return the text content of the long description, whereas what we need to write into pyproject.toml is the name of a file containing (what setuptools calls) the long description - in other words, the name of the readme file. What I've done here to handle that is dig into the more obscure fields of the Distribution object to find where it stores the original, raw value of the long_description field, and if that field starts with `file:`, I extract the filename and copy it over into pyproject.toml. On the other hand, if the long_description is a string, I've made it write that string out to a file and put the filename in pyproject.toml. The file is named with an extension corresponding to the content type if available; I introduced a bit of custom code to find the extension for a given content type to work around a bug in older versions of Python. This makes the plugin do something that has not been done for any previous field, namely creating a brand new file that needs to become part of the project being converted. I'm not sure how best to handle this. The current implementation is fine to get something that basically works, but it might be better to issue some kind of a warning or notification to the user that a new file was created, or perhaps exit with an error that prompts the user to explicitly specify that it's okay to write a new file with a command-line option. (Maybe that option could accept the new filename as an argument.) We should probably revisit this in the future based on what seems to be most useful. The content type is a bit more straightforward: I can just copy it from setuptools into the pyproject data structure, if it's there, and if not I just use a string value for the `readme` field. I have not made any effort to have the code guess the content type based on the content of the long description. That's something we could potentially add in the future, but it's going beyond what I have in mind as the purpose of this plugin, which is to copy information from setuptools to pyproject.toml as faithfully as possible.
These tests exercise a variety of configurations of the readme field in pyproject.toml: with or without a content type, referring to an existing file or a new one that the plugin has to create, and with various file types/extensions.
This commit adds the expected result for the readme field to test_everything(). I also stuck in a content type so that the input includes as many fields as possible (since that's the point of the test).
|
I know I had mentioned adding tests that use |
sjlongland
approved these changes
Aug 20, 2023
|
That makes sense… I would have thought We didn't know this at the start… we've only just discovered that little gem. We'll come back to the inline case later I think. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request adds support for readme files, populated by what setuptools calls the long description. This one is a bit more complicated because the naive way to get the field value,
get_long_description(), reads the content of the readme file if one is specified, but we need the actual filename to write intopyproject.toml, so I went a little deep into theDistributionmetadata to find the raw value.The other notable thing about this bit of code is that it will actually write the long description to a file if it was hard-coded in the setuptools parameters. This is the first case in which the plugin generates something other than the content of a
pyproject.tomlfile.