What is the current state of this discussion of plugins in spyder? I have been using django and django-cms lately and I know Spyder is not a framework (like django is), but would it make sense to provide some decoupling of a spyder base and the different plugins so that they could be pip installable and maybe easier to maintain?
I am right now in the process of adding a conda package manager plugin but I have been thinking of other plugins that could make work easier in many other fields/directions that could leverage on a core. On the long run when Spyder moves to github (which is something that is almost agreed on as I understand) and hopefully more contributors jump on board we should make it easier to develop spyder and plugins for spyder. Making all the plugins live inside the main repo will make in the future spyder much harder to maintain (or at least more annoying?). Just as Django has a ton of packages that enhance functionality and play (in theory) nicely together, and depend on spyder, could we make something on this direction happen maybe by doing a bit of metaclassing to simplify the definition of plugin base classes? Right now there is a compatibility library for py2 and py3 that lives within spyder but there is also 'six' so if six takes care of that spyder does not have to.... We could have something like pip install spyder-plugin-conda pip install spyder-plugin-x pip install spyder-plugin-y and spyder should be able to autodiscover this plugins and allow for enabling or disabling them (dialog...) Spyder plugins should be able to run by themselves (but depend on other modules inside spyderlib or even by separating modules from spyder that deal with this, the 'six' example...) We could even have something like spyder-qtwidgets or whatever and have a set of widgets defined in there. I am also aware there are few developers/contributors right now and this seems like a daunting move, but in the long run I think it would pay off tremendously as plugins can be maintained by their own developers, without having the core of spyder contributors worry about this, except for having a clear and hopefully not so volatile plugin-api. Cheers On Wednesday, December 11, 2013 8:39:43 PM UTC+1, anatoly techtonik wrote: > > I am not a favor of mimicking other approaches. Spyder is a scientific > IDE, so > there should some research first. Usability research that will make it > better than > others. > > About updates sites of ImageJ. I really doubt it is secure. Without > https://, > certificates and checksums the update process can easily be hacked to > install > altered plugins into your source code tree to steal you next scientific > discovery. =) > > Guys from distutils made a great effort to protect the communication > channel > between user system and PyPI in last year. They didn't have other choice. > It is > now complicated and may not be reliable, because some issues are hard to > check. I don't want to mess with that stuff in Spyder. So, no third-party > update > sites, but.. > > To simplify things, there can be registry, *but.. it is step 2* (year > 2015+). The > registry of approved (signed?) hash#size values comes shipped with Spyder. > hash#size lookup is made against plugin repository/wiki page, to fund a > link that > matches hash#size. Even if download site gives you malicious package, if > the > hash#size won't match, it will be ignored. Today it is possible to craft > files that > match given md5 hash for sure, but I'd like to know if sha1+filesize > limitation > makes it practically impossible? Anyway, this is a plan for distant future. > > *Step 1*. > In closest perspective, the plugin discovery should be done by lookup from > certain known locations + paths in Spyder config to reference to unknown > paths (I like using things from repository checkouts). Config can also be > used > to quickly enable/disable plugins. I'd like to avoid installation, > unpacking and > safety checking. If `pip` can do this securely - I'd fully trust it. > > I am against Python-wide plugin installation. Plugins have nothing to do > with > Python installations - I may run multiple Spyder versions (flavors) with > the > same interpreter and I don't want plugins to popup from nowhere and crash > IDE due to incompatible API. > > So, let's concentrate on lookup order first, then on config with custom > paths, > then think about everything else. `installation` will be dialog with > optional > autodiscovery, but with obligatory manual way to add plugin by specifying a > path to it. > > Going with Bitbucket /contrib/ or /plugins/ IMHO is a good way for the > starter > of third-party plugins and work on decoupled API. > > -- You received this message because you are subscribed to the Google Groups "spyder" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/spyderlib. For more options, visit https://groups.google.com/d/optout.
