In another thread there came an idea about a plugin manager. There I told I have an idea about a system which doesn’t need an extra server or service and which could itself be a plugin, not needing C++ coding. Now I have a proof of concept. Check out https://github.com/kc-plugin-publishers.
It’s just a command line script, not really a plugin. It just shows the idea of how the existing github (or some other) service can be used as infrastructure and how the scripts don’t need any packaging or tweaking. The plugin list repository is meant to be near zero-mainenance, except that people (plugin publishers) have to write and maintain the description files.
This is actually not dependent on KiCad in any way but can later be integrated to it and uses a simple KiCad plugin as an example.
If you are interested in developing this idea further, please join the github organization. I don’t promise anything myself, I count on you.
This works for Action Plugins, there are other types of “plugin”.
The problem I have with this is it adds another (now 4) different ways of managing downloadable content in KiCad. I think if any new plugin manager system is proposed, it must be extendable to all types of content (footprints, symbols, templates, footprint wizards, 3d models, etc ).
Additionally, your system requires a central repo which contains the “manifest” files for each plugin. I would put the manifest file in the plugin repos, then all that is required to use it is the URL of the manifest file.
I have been working on a gui (wxPython, of course). It’s not ready to be committed yet and at first will have only very basic functionality: it downloads the plugin list from a repository, shows the list and shows some details of the selected plugin. I will commit it when I get it to work as an Action Plugin. Then I have to implement actual installing - it works already from cli but not from gui.
That’s much more ambitious and out of my abilities. I’m not sure what to say. Yes, that would be ideal.
That wouldn’t lessen the work, you still would need the manifest file and some master repo to have those URLs. My systems could be adapted so that individual manifest files could be downloaded from anywhere; the user could give the URL directly or they could be kept in one central place.
The downside of having the manifest files in the plugin repos would be that the script writers should write or commit the manifest files. In my system (a centralized manifest repo) anyone could write and manage them. Like in Linux distros - the upstream doesn’t have to know anything about packaging and distributing.
It’s been developed on Linux, but naturally I want it to be platform independent. I of course try to avoid any platform-dependent things. I don’t have a Mac and should fire up an old Win laptop.
There’s a bug in KiCad: only on Linux the plugins are searched for from the user’s home directory. I have filed a report, please vote for it or comment. I think it’s one of those little problems which nowadays make the python support on KiCad a second class citizen. https://bugs.launchpad.net/kicad/+bug/1740776
I’m ready to discuss and can try to contribute to a better alternative. Of course I’m defensive for my own project, but I have the well-being of the community on my mind. I have spent some time thinking about my own system and it takes some time and effort to understand other possibilites and pros and cons of different systems. If you have something more to say, e.g. concrete architectures, file formats, implementations etc., please continue.
Don’t be so negative. Maybe give a reasoning why you are skeptical.
I think the plugin manager for freecad does it as @eelik wants to implement it. So i would guess something similar does already work. (And as @eelik already stated having a central repo that holds the package descriptions is basically how every linux package manager works.)
One important thing which I had in mind from the beginning: a plugin manager doesn’t have to be coded in C++, it could be mostly an independent project. Python is quicker and easier to develop with than C++ and an independent python project would free the core developers. No matter what the plugin manager would manage. It may need some entry points (API support) in C++ code, possibly nothing more. This was an important part of my original idea - that the plugin manager could be a python plugin itself.
If you think that users are better to write the manifest files than the script authors, then I think you need to spend more time thinking about it!
This is the classic shrug off. A technical improvement is rejected on “lack of resource” grounds. I didn’t say you need to implement it, that is what collaboration is for and why you asked people to help!
Specifying an architecture takes little effort, but enables other people to provide the implementation. I think if you call it “one script to rule them all” it implies general support? Better call it “one script to rule them all (but actually only action scripts)”
Anyway, this will be another one of those half-finished things that doesn’t fit with anything else and gets abandoned when the lead loses interest.
Sure and those distros have teams of people to manage the list. That creates a resource bottleneck which I am sure you are aware is a crucial issue in KiCad. Leave as much as possible to the contributors so that it doesn’t need constant maintenance.
Peer support is not unconditional, you have to adapt. Collaboration is a two way street. “My way or the highway” is self limiting. If you just want to hire people to do your bidding, try freelancer.com.
Continue what you are doing, maybe I can fork it later.
I assume the idea behind having a central repo is such that the plugin developers them selves add their plugin to it. This makes for a good user experience as the user has one place where they can lookup what scripts are available.
A bonus would be if the manager can add additional repos where it looks up further plugins. Maybe even a way to install plugins without the need for them being linked from such a repo.
I further assume that the central repo will only contain a short description for the plugin, the “download” link and the name of the plugin and author.
Versioning should be done in the repo of the developers. (That way plugin developers only need to register their plugin once.)
That’s what I’m trying to do here. What more do you want? I don’t understand anymore. All the time I have wanted collaboration, that’s why I started a project which didn’t have competition and I felt there was a place for it. All the time I wanted that I could let it go in one way or another so that something better could come out of it. You, on the other hand, haven’t yet given much positive contribution except your general idea about support for all kinds of contents.
Yes. Anyone can write and add a manifest file, including the original developer.
It can already do that. The problem from a user’s point of view is that in the end there must be some central list; otherwise he/she must hunt down scripts.
I do not really like to put additional workload on developers. The plugins could be stored in config_path. But this would need to be tested on all platforms if an action plugin has write privileges there. And if it has, how is it accessed in python.
Did you see the bug report? It should be a very simple fix, I just haven’t had an opportunity to try it on Win os Mac because it would require compiling KiCad and I don’t have a Mac at all. The idea is that in the KiCad source code there are already paths to search; right now on Mac and Windows only the system-wide directories are used which require priviledges. Only on Linux you can (right now) put scripts into your own home directory under .kicad_plugins/. That would need fixing on Win and Mac so that the user’s own directory can be used, and the fix is very simple.
I think I understand where bobc’s frustration is coming from. It is fragmentation. It is present in a lot of open source projects. As the code is available anybody with a minute to spare can make some kind of extension. After some time you have a system with which you can do a lot of things, but you have to set it up from various sources. Additionally some developers are not really experienced and their extensions might not be compatible with somebody else’s, just because of the wrong setup of their extension.
So when you see how much effort was put in, but nobody can really make use of it, it is quite sad.
Comming to the subject at hand. Yes the solution is intended for action plugins. But hopefully we will learn something from that, and if we do and if we don’t give up, it might be extended for other plugins as well (I am not certain, but I think all of the plugins are contained in the same folders, so this should be doable), so at least plugins would be covered.
To also cover footprints, symbols, templates and 3D models is beyond current KiCad python capabilities. Such a download manager would have to be accessible from Kicad launcher. And it would require cooperation from the Kicad developers. Though the idea is really good.
People like me ask what I can do now and what I can do alone as I’ve never really worked in a big open source project. With pcbnew python support and as I know a bit of python (but C++ scares me) I can write an action plugin and I can put a GUI on top of it. And I go and I do it.