Create devel docs #282
Create devel docs #282
Conversation
| flog.fields(collection_install_dir=collection_install_dir).debug('collection install dir') | ||
|
|
||
| # Install the collections | ||
| asyncio_run(install_together(collection_tarballs.values(), collection_install_dir)) |
There was a problem hiding this comment.
Looking at this I wonder if you considered using anyio? It has a nice set abstractions on top of various IO loop implementations (namely asyncio, trio and curio).
There was a problem hiding this comment.
@abadger I think that's more a question for you, since you introduced asyncio :)
There was a problem hiding this comment.
I've played with trio and curio a little bit in my spare time and I like the concepts that they push better than the ones that asyncio does. I haven't used them enough to know whether ecosystem support is needed to make good use of them, though (as in, can we use aiofiles and aiohttp directly with trio or will we need to start using a different library or will we need to write our own routines). I stopped playing when I got to the point of working on making urwid compatible with trio (but that was a special case since urwid has its own event system which it plugs into the event loop. Other libraries might work without needing to be ported... I don't know for sure). I haven't looked at whether anyio implements any concepts in addition to trio; the documentation makes it looks more like you get trio-like concepts with asyncio as your backend.
I don't think switching away from asyncio right now is a good use of time, though. The patterns of things that we're doing are pretty well established; there's most likely code somewhere else in the code base that shows you how you should be writing your code to work in parallel. Switching to a different API will require rewriting or at least auditing those patterns to see if they work the same in the other async framework. Perhaps in the future we could replace asyncio with something else. It would need exploration to see just how much work it would be, though.
if anyio is truly just a way to get trio/curio-like semantics on top of asyncio, I think I'd rather port to trio directly. But I don't know enough about anyio yet to make that call.
In any case, I think changing the async framework we're using is a separate discussion than this one.
…el builds match where applicable.
|
Looks good to merge. I think I want to work on moving the portions of stable.py that are being imported by other doc_commands into their own file. Possibly making it library code or possibly making it helper functions for the app-level code. (It's not clear in my mind, yet, which side of that line these functions fall under). I'll work on that as a follow up PR once this merged. |
|
@webknjaz @abadger thanks for reviewing and merging!
That's definitely a good idea! But maybe it makes sense to wait with this until #272 is done, since it (at least currently) makes some changes to the code in stable.py. |
Implements
antsibull-docs devel. I copied the functions indevel.pyfromstable.pyand made minimal adjustments.