Stephan Raue a écrit : > what about with a option to setup.py to let the packagers set up the > path(s). moovida can search the paths if any plugins are available. if > moovida supports more then one path packagers can setup paths for > plugins that are distributed and (then) plugins installed by users/moovida > > Stephan
Yes, letting the packagers decide where to install system-wide plugins makes sense (as long as it's not in the pythonpath but in a dedicated directory). But that means moovida needs to be informed of the path where these plugins are installed at startup. Is there any standard mechanism for this? Let the packages hardcode this path in the launcher when installing the plugins maybe? > Am 19.06.2009 18:18, schrieb Olivier Tilloy: >> Hi Moovida developers/packagers, >> >> This mail is mostly intended for people concerned about and with >> knowledge on packaging issues (but all crazy suggestions are welcome too!). >> >> I'm starting to think how we could improve the way Moovida's plugin >> registry handles (discovers, loads, installs, ignores, updates, etc...) >> plugins, and I'd like to collect the widest range of input and >> suggestions so that we avoid running into problems like we regularly >> have with the current plugin registry. >> >> On one hand, we have the basic set of plugins that are installed by >> default (on windows with the installer we provide, on linux in packages >> provided by the distribution or kind packagers). On the other hand we >> have "external" plugins which we want to make available easily from >> inside Moovida (a one-click download & install in the user's home >> directory). >> >> There is a large variety of scenarii (I remember this discussion on the >> ML, for which I can't find the thread any longer, about distribution >> packagers wanting to be able to fine control the installation of >> external plugins, possibly forbiding it, and be able to dynamically >> differentiate system-wide installed plugins from user-installed >> plugins), and a good re-work of the mechanism should take them all into >> account. >> >> My first important concern is about plugins being installed in the >> python path on linux. This doesn't make sense as they are not standalone >> python modules, and it forces us to do some ugly hacks with the python >> path to (sort of) control how we load them (those hacks proved to be >> weak and bug-prone in numerous occasions in the past). >> >> So, in your opinion, where should the system-wide plugins be installed >> on your favourite distribution? >> >> As a starting point, I've compiled a incomplete list of applications >> that have a plugin system and where they install their plugins on my >> ubuntu intrepid system: >> >> - rhythmbox: plugins in /usr/lib/rhythmbox/plugins/ >> - bzr: plugins in /usr/share/pyshared/bzrlib/plugins/ >> - banshee: extensions in /usr/lib/banshee-1/Extensions/ >> - firefox: extensions in /usr/share/mozilla-extensions/ >> - thunderbird: extensions in /usr/lib/thunderbird/extensions/ >> - totem: plugins in /usr/lib/totem/plugins/ >> - eclipse: plugins in /usr/lib/eclipse/plugins/ >> >> Don't hesitate to complete this list or compare the same applications on >> other distributions. >> >> Please note that this is only a preliminary brainstorm, re-writing the >> plugin registry (even partially) is neither started nor even planned >> yet, I'm just collecting ideas and knowledge. >> >> Cheers, >> >> Olivier
