Author Readme files for each library and integrate into the PyPi descriptions. Fixes #156#157
Conversation
…g descriptions. Those descriptions should show up in PyPi. This is following thie guidance found on Python Packaging here: https://packaging.python.org/en/latest/guides/making-a-pypi-friendly-readme/
…in pyproject.toml for PyPi compatibility Lean into the newer PEP 621 metadata approach we're already using, rather than using the older long_description approach.
…ve long description from setup.py
…ve SDK descriptions, package overviews, and sample application links for improved developer guidance.
|
@cleemullins Food for thought, not a no... I had originally played with providing sample code in these README's, then decided it was a doc maintenance problem. What about just links to Learn documents so that samples (etc) is in one place? |
Reasonable, but the samples (and really all the readme) is generated by an LLM on analysis of our repo. There's no hand-rolled samples or code in there. Now, if we were spiffy, we would auto generate the entire readme from a template on each merge to main. Using a readme.md template, this seems practical. I started going down that route, but would have spent more time doing that (by far) than just using a prompt and generating them. |
rodrigobr-msft
left a comment
rodrigobr-msft
left a comment
There was a problem hiding this comment.
There is a lot of code here, and this is a more accessible (more visible) source of examples than even our samples. For that reason, I think we should treat the code examples here the same. If we are going to provide this much code in our READMEs on PyPI, then I would make sure it's well tested. I haven't looked through all of the READMEs to save time because it also don't feel right to verify this code via inspection alone.
…e's for maintainability.
3 participants
Fixes #156
Following guidance found on Python Packaging
This means:
As we move forward, updating the package descriptions is just a change to the relevant readme files.