[Qgis-developer] Python Plugin Repository - plugins app first working version

Martin Dobias wonder.sk at gmail.com
Sun Nov 28 12:24:28 EST 2010


Hi Alessandro!

On Fri, Nov 26, 2010 at 6:28 PM, Alessandro Pasotti <apasotti at gmail.com> wrote:
> Hi,
> I've just uploaded the first working version of the new Python plugins
> Django app.

I've just tried it - and it's great stuff, working very well!

> Implementation is hopefully complete but it still needs testing,
> authentication is also missing since it should be handled by an external
> provider (ldap ?) but for testing as a logged in user you can log in through
> the admin panel.

I think log in / log out can be added now (just without registration)
- if I understand it correctly, once we know how to deal with the ldap
server, we will just switch over to ldap authentication backend from
the default one. Not having log in/out facility makes the testing
harder as it's not possible to log in as ordinary user (only staff is
allowed to login to admin interface).

> A few open questions still remain:
> 1 - metadata are read from the zip file on plugin creation and that is fine,
> but what happens when a new version of an existing plugin is uploaded and
> there is a conflict in metadata plugin's name ? Should the plugin name name
> be updated with the new plugin name or just fail? I guess that updating
> description is just fine but changing plugin's name it isn't, so I put some
> validation in place to avoid name mismatch or (worse) having different names
> in the DB and in the zip packages.

Inside QGIS we make a difference between plugin name (user-readable)
and plugin package name (the directory of the plugin). We require the
package names to be unique. I think it will be good to add 'package
name' attribute to plugin model, strictly require it to remain the
same and update plugin's name from the metadata on updates. Does this
sound good to you?

> 2 - according to specs, the users are initially untrusted and they cannot
> publish their plugins. When a staff member grants the "trust" to the user,
> he can publish all his plugins. Plugins have a creator and 0 or more
> "owners" who can manage the plugin exactly as if they were the original
> author. Common sense says that if a user i not "trusted" and he uploads a
> new versions, the whole plugin should be unpublished (remember the published
> flag is in the Version model)

I think a reasonable requirement would be to allow adding only trusted
users as co-owners of a plugin. In case someone is willing to add an
untrusted user, he can solve that with admins (e.g. mail them to
request setting the other user as trusted) - this probably won't be a
common case.

> 3 - "last" version in the two "branches" stable/experimental i somewhat
> tricky (and IMHO the name is misleading, since if "last" has to do with
> time, the upload time should suffice to determine which version is the last
> one). I did not put too much magic in the code and this part can be improved
> for sure.
> So, I'm not sure that the workflow I have implemented is what you had in
> your mind.

I agree that "last" version is somewhat misleading. So let's call it
rather "current" version (stable/experimental). My idea was that it
would be an attribute of each plugin which version is the current one
(and not to have a "current" flag for each plugin version). Setting
the current version should be thus possible e.g. in "edit plugin" form
using a combo box listing available versions.

> I need your help in
> * testing the application
> * check the english strings (I'm not sure about them)
> * ldap authentication
> * styles: I've stolen the CSS from main QGIS site, ponies are warmly
> welcome!

I have various notes from my testing, mostly smaller things regarding
the gui which are probably not that imporant right now. Apart from the
log in/out and handling of current stable/experimental version, not
many functional additions/changes are required. One important missing
piece is a generated XML document of the repository which could be
used by the plugin installer.

Later I will try to give it another round of testing and write down
any issues (or even fix them if I find some time).

After some more polishing and testing we should be able to put an
experimental instance on the qgis.org site and once everything works
smoothly, ask authors to start migrating to the new repository.

> last note: the app was built to be "portable", so moving it around and
> changing the routing (urls.py) should work without problems. I also resisted
> to the temptation to use custom triggers in the DB.

Great.

> See the Makefile for some useful dev targets and the docs folder for a (very
> short) introduction.
> Happy testing !
> https://github.com/qgis/qgis-django/

Thanks for your work!

Martin


More information about the Qgis-developer mailing list