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]
<mailto:[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
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.
