René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"New canopen-asyncio or migrate asyncio into canopen?","articleBody":"I'm maintaining the canopen asyncio port https://github.com/sveinse/canopen-asyncio. The port is gaining in popularity and I need to decide what we should do next and where to put the efforts. Two main options:\n\na) Import the asyncio port to the main library, or\nb) Make the asyncio into a separate, indepenent package\n\nThe port is functional, but not complete. More precisely, not at the same level of maturity as canopen. Tests are missing and some functions cia profiles (like 402), LSS, etc are incomplete.\n\nThe main question is: How mature do we need asyncio to be to be able to merge it into canopen? Continue on #272 and PR #359. The canopen project is not very big and we aren't that many maintainers, so I think I'm not mistaking if I'm saying this: I suspect it will take a while to get asyncio implemented.\n\nI'd like to see the canopen asyncio published on pypi rather soon. People are using it and the current git reference to the asyncio fork is very tedious. The fork use the same package namespace \"canopen\", which makes it unsuited for a publish as-is. If option (b) involves renaming the source and package name to something unique, and it will be separate from the canopen package. Going down that route will require more efforts to keep the two projects in sync later. PRs won't work.\n\nMy intent with this post is to gauge how much interest there is to do the work of getting asyncio into canopen. Because if there isn't really any capacity to so, it might be best to split this out into a separate project.\n","author":{"url":"https://github.com/sveinse","@type":"Person","name":"sveinse"},"datePublished":"2025-04-22T19:51:45.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":5},"url":"https://github.com/569/canopen/issues/569"}