Replies: 25 comments 9 replies
-
@zariiii9003 You proposed having more plugins. Is there currently even any documentation on how to do this? I could only find the note at the bottom of this page of the docs. cc @hardbyte |
Beta Was this translation helpful? Give feedback.
-
This package provides an individual or company with the ability to interface with a CAN bus at a comparatively low cost. With that, I'm going to second @zariiii9003, that lesser known interfaces should not be included in the package (primarily for the sake of maintainability), but rather up to the individual to utilize |
Beta Was this translation helpful? Give feedback.
-
I'm also +1 for making more use of the plugin API. However, this might slow adoption of this library since it is possible that some users find maintaining a separate package cumbersome. But I'd say: then the interface is probably not important enough. |
Beta Was this translation helpful? Give feedback.
-
We could have similar discussion on file I/O (see here).
@zariiii9003 added:
|
Beta Was this translation helpful? Give feedback.
-
We could ask the community to vote on an issue/PR or comment what they would use it for? Maybe there is too little interaction though to get this to work well. |
Beta Was this translation helpful? Give feedback.
-
Perhaps if a package that implements a plugin gains enough traction we could add a documentation page containing "external plugin/interface" packages that are compatible with |
Beta Was this translation helpful? Give feedback.
-
Sure, we should definitely add it to the python-can docs. But also point to the respective external repos for docs & issues to make it clear that others are responsible. I wonder whether we should provide some template repo to get people started. It would ideally have the plugin connection for a simple file I/O reader/writer pair and a dummy interface set up and maybe a trimmed version of our CI pipeline. That way, people would probably be more willing to maintain their own variants. It can't be too hard to set up (by mostly copying), can it? Maybe also include a link/code snippet on how to upload to PyP and what to do to include it in the mainline (python-can) docs. |
Beta Was this translation helpful? Give feedback.
-
Slight tangent: Do we need to keep the mailing list? It seems like having an additional platform doesn't simplify things, and if discussion take place on GitHub maybe others will join in and assist. Maybe it's because I'm rather young, but I don't see the benefit of the mailing list (at all). |
Beta Was this translation helpful? Give feedback.
-
Having just gone through the docs for all the interfaces I'm in favor of removing the lower quality and/or lesser used ones. I don't see a problem pointing people to external plugins (similar to the external virtual interfaces). A template repo or cookie cutter recipe sounds like a very good idea to support that. Mailing list... I'm also not a fan. I might just remove reference from the readme while I'm editing docs. I've only briefly looked at GitHub's support for discussions - we could enable that and give it a go? |
Beta Was this translation helpful? Give feedback.
-
One other thing that might help with maintenance of the existing interfaces and custom io would be adding a CODE OWNERS file so the original contributor gets notified/review requests for subsequent changes. |
Beta Was this translation helpful? Give feedback.
-
Sounds good. I'd also rename it (if that is possible) to something like "python-can (archive only, abandoned)" and maybe we should write a "last" email to tell people not not expect active discussions in there any more.
I don't have experience on that, but I personally am fine with having everything be an issue, possibly tagged as |
Beta Was this translation helpful? Give feedback.
-
I would prefer using Github discussions, so the issues are only used for actual bug reports. +1 for the template repo with Bus and IO-Plugins. The CODE OWNERS file would be great, but it only works for users with write access to the repo, right? |
Beta Was this translation helpful? Give feedback.
-
"The people you choose as code owners must have write permissions for the repository." |
Beta Was this translation helpful? Give feedback.
-
+1 |
Beta Was this translation helpful? Give feedback.
-
:-) I really feel honored! But in fact I need to learn and practice Python first before I can feel a 'code owner'. |
Beta Was this translation helpful? Give feedback.
-
I'm not really sure how you plan to split up the project or not.
?? Especially when there would be a proper (plug-in?) interface for Or am I on the wrong page? |
Beta Was this translation helpful? Give feedback.
-
python-can offers "entry points" where other packages can register their own classes. See some example packages here, here or here. We're not talking about splitting the library. However, we might need to talk about moving some unused/unmaintained interfaces outside of python-can. |
Beta Was this translation helpful? Give feedback.
-
@hartkopp There's no certificate needed to be a code owner. ;) You already have the expertise to help. To be clear: The idea is not to split the library entirely. Instead commonly used (=important) and well maintained interfaces/file type support stays in the core library in this repository. But other less mature or seldomly used functionality will reside in extra repositories to not carry the maintenance burden here. |
Beta Was this translation helpful? Give feedback.
-
@zariiii9003 @felixdivo |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Just two notes on this:
|
Beta Was this translation helpful? Give feedback.
-
What do you think about using towncrier and forcing all PRs to have a news fragment? With towncrier we wouldn't need to search for changes and create a changelog manually. Maybe it would help with creating spontaneous releases. |
Beta Was this translation helpful? Give feedback.
-
@hardbyte Should we remove old pre-releases from the github releases page? |
Beta Was this translation helpful? Give feedback.
-
Here, the discussion on how to keep or even just make python-can more maintainable was raised the last time. Let's continue here.
Beta Was this translation helpful? Give feedback.
All reactions