Conversation
|
Added fix for mypy error, taken from d52b093 |
|
cc @cburgdorf who is our resident documentation expert. |
|
For reference, here's an excerpt of the global makefile we use to build docs in Trinity: https://github.com/ethereum/trinity/blob/24213d8f22a03c370313d3a990eea6a2fe1e76e4/Makefile#L43-L57 I'm happy to take a look at this PR tomorrow. |
carver
left a comment
There was a problem hiding this comment.
Now that I look deeper, I'm seeing a bunch of things that I would like to see added, like towncrier support for release notes. If you'd like, I can pick it up from here and add more of these things.
| """ | ||
| if self.event_local_closed.is_set(): | ||
| raise MplexStreamClosed(f"cannot write to closed stream: data={data}") | ||
| raise MplexStreamClosed(f"cannot write to closed stream: data={data!r}") |
There was a problem hiding this comment.
I'd recommend this one to be moved to another PR, it should be a very quick 👍
There was a problem hiding this comment.
It seems like this is already resolved in master with d52b093. I have merged it into my PR branch and the changes are resolved correctly.
| if msg_bytes[-1:] != b"\n": | ||
| raise ParseError( | ||
| f'`msg_bytes` is not delimited by b"\\n": `msg_bytes`={msg_bytes}' | ||
| f'`msg_bytes` is not delimited by b"\\n": `msg_bytes`={msg_bytes!r}' |
There was a problem hiding this comment.
This one can also be added to that separate PR.
setup.py
Outdated
| "flake8>=3.7.7,<4.0.0", | ||
| ], | ||
| "dev": ["tox>=3.13.2,<4.0.0"], | ||
| "dev": ["tox>=3.13.2,<4.0.0", "Sphinx>=2.2.0,<3.0.0", "sphinx-rtd-theme"], |
There was a problem hiding this comment.
It can be nice to move this to its own doc extra, like:
https://github.com/ethereum/trinity/blob/0ef04653c17d726463ae8a7f0ac01e0dcd930d54/setup.py#L85-L91
| @@ -0,0 +1,17 @@ | |||
| Welcome to py-libp2p's documentation! | |||
There was a problem hiding this comment.
We have a few general documentation guidelines, and we're trying to make sure that all our repos are as close to them as possible.
That's why I'm taking this opportunity to point this out so that we can get these policies involved early on.
It's far from perfect but the project closest to the ideals of this guide line is probably Trinity so I recommend to take a look at its docs.
In particular, it would be nice if we could roughly follow this navigation structure.
General
Introduction: The landing page, giving a quick overview about the project, additional pointers.
Quickstart: Pretty much what you already have with all the installation instructions
Release Notes: Points to the towncrier generated release notes
Fundamentals
API: Source generated API docs as you already have them included in the PR
Cookbook: Collection of small recipes, examples. Doesn't need to exist in the beginning
Guides: Tutorial style guides. It's ok to just have a link to the Quickstart here to begin with
Community
Contributing: Instructions on how to contribute to the project
Code of Conduct: The code of conduct that we use across repos
| Stable release | ||
| -------------- | ||
|
|
||
| To install :code:`py-libp2p`:, run this command in your terminal: |
There was a problem hiding this comment.
There's no right or wrong when it comes to the narrative perspective but we chose to use the first-person "we" form which means there is rarely ever a place for "you" in our docs.
E.g. see Trinity's quickstart written in first person "we" form
|
Docs reorged and more in #454 |

This PR will
Swarm.listendocstringWith this PR merged, documentation can be built locally by entering the docs folder and using the Makefile:
The output can be found in the
builddirectory, in the case ofhtmldocs, it can be opened atdocs/build/html/index.html. A variety of other documentation formats are available and can be checked out by using the Makefile's help command:New documentation can be added by simply manipulating the code components' docstrings, or explicitly by editing the
rstfiles in the docs folder. These files mirror 1:1 the module structure of the library at the moment and should be adapted in case larger refactorings take place. This makes it easy for developers already familiar with the project structure to also contribute to the documentation if further explanation is needed.The goal of this PR is to lay the foundation for further exhaustive documentation of each code component (ref. #318, #90, #35), as well as improving docstring quality and guiding future refactors leading
py-libp2pto a state where we can remove the WIP label from it. 🙂