[Qgis-developer] The new QGIS plugin repo

[Borys Jurgiel]

Dnia poniedziałek, 28 czerwca 2010 o 15:02:11 Carson Farmer napisał(a):
> Howdy Borys et al.
> 
> Will it be possible to control access to a particular plugin in the
> central repository? In some cases, a developer (or a team of
> developers) will prefer to limit changes/developments to their own
> team (in some cases, this is a requirement of funding). 

Of course! The plugin owner and repo admins would be allowed to grant and take 
away the privileges. We can even think about separate disk space and webpage 
for each author.

> I am pleased
> to hear that external repositories will still be usable, wouldn't it
> be relatively simple to have a web interface where authors could
> submit their repository, and then have the installer simply add these
> repos if the user wishes to add them? My concern with a completely
> centralised system is that while we gain in control and (potentially)
> stability, we lose in flexibility, and quite possibly usability. As it
> is (fyi: I am not necessarily suggesting the current way is the way
> things should be), it is quite easy for plugin authors to create a
> plugin, create a repo, and host their plugins for all to access.
> However, as you have mentioned, we (Borys) need to hard-code the repos
> to the plugin installer for them to be added to the 'add 3rd party
> repos' button, Well what about if the installer simply fetched a list
> of 3rd party repos from the server, based on a list of submitted repos
> via a web interface similar to the one for adding plugins to the
> current repository? This alleviates the pressure on Borys and the rest
> of the team in terms of keeping things up to date, and the repos that
> are down will simply time-out, and if the repos have problems, their
> plugins will simple not be available until those problems are fixed?

Do you suggest to manually block whole repository every time I discover that 
one of its plugins contains a small mismatch in metadata (e.g. causing the 
stubborn false upgradeable status)? It would affect users of other plugins...

Also it doesn't resolve connection problems. As far as I can hear it's quite 
irritating for some users (me too) to wait for fetching all repos and kill 
hanging connections.

I prefer our primary idea of proxying and automatic testing of each plugin, 
but it seems to be an unnecessary complication. I'd prefer to spend this time 
on building an author-friendly central repo and encourage authors to use it 
rather than on building such weird proxy :) It would take weeks of writing 
such application and will give relatively small profit. 

All I want to do is to keep constrain some quality standards. The hand-made 
xml metadata and zip packages are not acceptable. You don't see that every 
week I send notices to authors of broken plugins - let's imagine what was if 
I'd break both hands and stop to poke them ;-DDD

It was good when there was only a few repositories, but now it's too more.

> Perhaps I am over simplifying things here, but my concern is that we
> will loose many valuable plugins simply because we are imposing
> structure on plugin developers who may not want it (i.e. they might
> already have their own code repository that they prefer using, or
> indeed do not want to have to learn an additional tool such as svn).

I don't believe someone would prefer to fight against metadata instead of 
simply use svn. There are many graphical clients, so commiting changes 
requires one rightclick. Instead, the present solution makes you to:

1. remove .pyc files
2. make the zip package
3. upload the package
4. update the version number in repo.xml
5. restart qgis
6. install the plugin to test the package and metadata
7. [ restore your development environment if damaged in the previous step]

If you don't test plugins every time after commit, better don't confess ;p

The real problem is marketing. I understand someone can prefer to keep all 
stuff in his domain... But instead, we can enable them to keep their 
trademarks and url in the installer, right next to the plugin description.

Anyway, I've just closed my repository and move all plugins to the contributed 
one :-)

> I hope I'm not being a pain here, but I want to make sure that any
> changes that are made, are only made if they significantly improve
> both the user and developer experience.

Sure! I'm glad to see a critical opinion in the end :)

B.