Hi Paul, Paul van Tilburg a écrit : > Hello Olivier, > > On Tue, Mar 17, 2009 at 02:36:02PM +0100, Olivier Tilloy wrote: >> Thanks, and sorry for the late reply. Have you checked out the latest >> release (0.5.32)? > > I have, and also 0.5.33 by now. ;) > > >>> I am one of the Debian Elisa maintainers and am not sure how to deal >>> with the update system yet. I've talked about it with some of you >>> on the IRC, but it might be better to discuss it here. >> Indeed there is a lot to be discussed. >> >>> It seems there are a few issues here: >>> >>> 1) There are plugins that are not distributed via -good, bad, or -ugly >>> AFAIK (apple_trailers, ted, etc.). For this the plugin (update) >>> system is essentially an installer for extra functionality that users >>> can select. If these plugins are never pulled into -good, -bad or >>> -ugly, they should be updated once the user installs them. Either >>> that, or we start distributing these plugins also. >> The plugin distributed externally are indeed never going to be shipped >> in -good, -bad, -ugly. In fact for some of them (and we hope most of >> them in the future) we don't even ship them, just link to them in our >> plugin repository. That allows us to easily bring to the users the best >> of the community developments. >> Now, I would say that's up to each distro to decide whether they find >> some external plugins good and interesting enough (and >> license-compatible) to ship them in external packages. > > I plan to package some of the plugins, as long as there is not demand, I > see no problem there. So, I think we can agree that even for an Elisa > instance distributed by some distribution such as Debian, plugins still > need to be available. That's why I haven't set update_plugin_cache to > False, just doesn't feel right to do so. > >>> 2) [...] Does Elisa to plugin cleaning? >> Currently not, that's something we need to implement. See >> https://bugs.launchpad.net/elisa/+bug/309161. > > Ah, ok.. subscribed. > >>> 3) Is Elisa aware of plugins (including the core) being not user but >>> distribution installed? >> Yes. Basically, at startup plugins are going to be searched in the >> PYTHONPATH + ~/.elisa-0.5/plugins/. >> If a more recent version of a distribution installed plugin is found in >> ~/.elisa-0.5/plugins/, it is going to supersede it. > > Right. But since people can arbitrarily change PYTHONPATH, there is > not a real two-step search of dist plugins and then user plugins. > So, it's not so easy to do as I initially thought.
Not really. But we have countless issues with this PYTHONPATH black magic we are doing internally, and I'm thinking of some cleanup to fix all that (but that's a background, not high priority task). Cleaning this up would eventually allow to implement a two-step search for plugins, for example. >>> If (3) is the case, we could maybe have an mode between completely >>> unawareness of any plugin updates at all and full plugin upgrades and >>> access to new plugins that Elisa has now, namely a 'dist' mode where >>> dist plugins are never upgraded, only new plugins can be installed and >>> updated. Also plugins that become 'dist' plugins at some point can be >>> cleaned automatically. >> That's a possibility indeed, that would require some modifications to >> the plugin registry. In fact I want to clean it up at some point, and >> this feature could be implemented at this point. Can you please open a >> bug report explaining the idea, and assign it to me? > > So I've thought about this more. And it seems quite an elegant solution > to me. At build time the eggs get the extra metadata flag 'dist' or > 'vendor', and when newer versions of the same plugin are found they are > discarded or the 'dist' one is considered the newest. Either way, this > would result in only adapting the "comparision function". However, I am > unaware of the current implementation. That goes down to what you state, basically adapting the comparison function. > Should I write the above in the bug report? Let me know. :) Yes please! > For me, not being able to block updates of these 'dist' plugins is the > main issue that prevents me uploading Elisa 0.5.x to Debian Sid. So, I > hope we can work out the above the idea or something completely > different. Even a temporary solution is fine, it doesn't have to be > perfect in one attempt, right? :) Anyway I think it will have to be a stepwise process if we want to get to a perfect plugin management in Elisa. > Kind regards, > Paul Cheers, Olivier
