Hi Joseph Yes indeed, it would be nice like that... if we still want to go in the conda way of things, this "problem" would be solved.. at least for science (our biggest user community)
conda install spyder-plugin-conda conda install spyder-plugin-pylint conda install spyder-plugin-profiler Or even better just using the conda package manager... Even if we do not find the time to make it happen (the actual code) I think it would really help if we managed to have some brainstorming session (IRC or google hangouts... or the like..) at least to gather some "consensus" or random ideas? And it would be nice also if this could be done in some sort of wiki or whatever to start looking at a common idea... (github wiki? or bitbucket?) What are the requirements, the needs the current bottlenecks and the roadmap. What would be a good folder structure for a plugin.. (locale, images... etc..) The current plugin API was a great improvement on the plugin definition, but I would like to see some simplification of the p_package.py modules. For development of plugins (while they are not pip or conda installable) there should be some spyder --plugin-dev option on startup to be able to load a plugin based on specific folder location and test it... Lots of ideas to test :) Cheers On Saturday, October 25, 2014 1:12:13 AM UTC+2, Joseph Martinot-Lagarde wrote: > > The state has stayed where we left it. > > pip-installable modules are good, but it should be possible to install > them without having admin rights. > > Plugins have made the success of many softwares (firefox and eclipse > come to mind) , and relying on users for less-used features would be > nice too. > > Now if only I could find some free time... > > Le 23/10/2014 18:36, Gonzalo A. PEÑA CASTELLANOS a écrit : > > 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] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to > > [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > Visit this group at http://groups.google.com/group/spyderlib. > > For more options, visit https://groups.google.com/d/optout. > > > On Saturday, October 25, 2014 1:12:13 AM UTC+2, Joseph Martinot-Lagarde wrote: > > The state has stayed where we left it. > > pip-installable modules are good, but it should be possible to install > them without having admin rights. > > Plugins have made the success of many softwares (firefox and eclipse > come to mind) , and relying on users for less-used features would be > nice too. > > Now if only I could find some free time... > > Le 23/10/2014 18:36, Gonzalo A. PEÑA CASTELLANOS a écrit : > > 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] <javascript:> > > <mailto:[email protected] <javascript:>>. > > To post to this group, send email to > > [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > Visit this group at http://groups.google.com/group/spyderlib. > > For more options, visit https://groups.google.com/d/optout. > > > -- 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.
