Hi, @Alessandro: Would you consider writing, or scaffolding, a Python class that assumes a correctly written and prepared plugin (i.e. properly packaged plugin) and the necessary extra textual information that is needed for the repository listing, and interfaces an upload to the repository app using its API? This is the first plugin I will be releasing, and I have not gone through the process of uploading to the new repo app yet. I could take your class and add a GUI onto it for the upload to plugins.qgis.org part of the Editor's upload tool.
After completing the Plugin Editor's tool set, I would like to wrap its packaging and uploading tools into two Eric4 plugins, so plugin developer's who move to (or start with) that IDE can have those tools available to them as well. @Paolo: What about the Editor plugin offering to auto-setup a Redmine git repo upon upload to the plugins.qgis.org repo app, if the plugin author hasn't set one up until then? Part of the package and upload tools' logic should be to verify and offer as much best practice functionality as possible, as this directly affects how the plugin is released to (seen by) the public. @all (sorry, this is a bit long-winded): After reading this discussion on requisites and best practice techniques, I'm noticing a need to define the anticipated base user for the Editor plugin. To do this I tried (incompletely, no doubt) to put together what is needed by a potential new plugin dev to create an 'ideal' QGIS plugin. I have also tried to put these requisites in some sense of functional order, i.e. what should be known first to produce an actual working plugin, not necessarily in any best practices order: * Read other plugin devs Python code and discern the logic. I think this is the root level of starting to learn any new coding technique, and the Editor is built around this principle. * Understand Python, and how to write procedural functions with it. OOP and PEPs are something many coders new to Python don't do right away. * Understand how the QGIS Python API works, i.e. what a Python binding is. This includes learning to read C++ class docs, an undertaking not usually associated with learning a single scripting language API. * How to use the Python Console to test code snippets. * Know how the parts of a plugin work (__init__.py, factory class, etc.). * How to test/debug the plugin. Plugin Editor has no debugging (though it could); but since it has the simple reload functionality (based on Richard Duivenvoorde's work), getting to QGIS's Python error traces is pretty quick. For example, I have not really needed to use a command line debugger when writing the Editor plugin (yet), just Richard's reloader plugin. * Understand how to build a GUI with PyQt. I think this is a big hurdle for many new devs (it was for me, since I didn't learn PyQt/Qt until needing to make a QGIS plugin). Learning PyQt, Qt, signals/slots, and Designer alone takes some time and head-scratching. * Creating a proper QGIS plugin deployment for use by others (not necessarily the public). Using 'make' to aid deployment seems fine to many devs, but most scripters have never had to learn how to write make files when working with an interpreted language. The functionality of a make file could be replaced with simple check-boxed include/exclude listing of project files in the GUI for stripping out unneeded resources. Compiling will already be done during deployment/packaging. * Learn how to use the new plugin repo for a plugin release. This may be the first time a coder has had to use or need a SCM. Having git available on hub.qgis.org will be a definite boon to those new to such things. * Learn how to work with users via a bug tracker, etc. and respond with fixes or new releases. * Learn QtWebKit, or similar tool, for creating good, embedded user documentation. * Learn how to internationalize the visible strings of the plugin. A cursory examination of currently available plugins shows this is not always at the top of most devs list. * Learn Sphynx to generate plugin documentation, especially if the pugin has public methods, etc. * Learn to write proper code (PEP adherence, use of PyLint, etc.). * Learn to work with other devs who may want to fork the plugin and introduce new code. * Learn to create unit tests (if they care about stability and not breaking code). * I'm sure there are others Let's assume some realistic, but proficient QGIS users who may want to try to develop a plugin... A) Know none of the above requisites. B) Know some Python, but never created plugins or GUIs with it before. C) Know some Python, created some plugins for other software, but no GUIs with it before. (<-- I started here) D) Know quite a bit of Python and have written some GUIs before (maybe with wxPython or PyQt) E) Know more than users A thru D. Given the above noted requisites for crafting a QGIS plugin, which should be considered the base user for my plugin? I'm designing for user A), for whom I think the Plugin Editor should a least offer a clear understanding of how to achieve not only writing a plugin, but also how to eventually meet the best practice requisites noted above, and offer the tools or links to resources to do so. The QGIS project has first-class, clearly written code and support documentation, created by driven developers and authors who try to meet high-quality OS standards. It would be good to gently push new plugin developers to strive to meet similar standards, but not at the price of the learning curve becoming a wall. I'm hoping that Plugin Editor will help new plugin developers enjoy their path to writing quality plugins by reducing learning obstacles to manageable steps. Any help with breaking down the requisites, and when they should be introduced to the neophyte developer (in the embedded tutorial) would be greatly appreciated. I'm striving to have the Plugin Editor qualify for 'user-friendly,' a status already achieved by QGIS, which is why I use it. Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
