Hi, Am Tue, 31 Jul 2018 23:18:32 +0200 schrieb Christian González <christian.gonza...@nerdocs.at>: > Whow, I'm quite impressed. Never stumbled upon that. I'll recommend > that for some collegues (to use it...)
Thanks =)
> But about the internals: Nice, this was the first way I implemented
> that as well, and maybe I will come back to that again. You have to
> restart the server as well if you want to enable a plugin, right?
If by enable you mean installing (in our terminology), yes. Normally,
you need to do something like
pip install pretix-myfancyplugin
python -m pretix migrate
python -m pretix rebuild
systemctl restart pretix
rebuild is a custom management command that compiles translation files,
SASS files and compressed JS files.
> From a security POV, I thought: who hinders anyone to write malicious
> code and provide an entry point for your system? maybe in a library
> you install... (but this is merely a philosophic question... don't
> bother.)
Nobody. But if you pip-install a library with malicious intents, you
have lost anyways, since its setup.py will likely be executed during
install (or at least some of its code will be executed once you import
it) and it can do whatever it wants anyway.
> But it's now replaced by entry points discovery. I had this too, (and
> will maybe come back to it). Setuptools' entry points discovery is a
> bit slow, but for the server start that doesn't matter, it's just
> once. (except development, you'll have to restart your server often)
> Your entrypoint is e.g. "pretix_pages=pretix_pages:PretixPluginMeta"
> - I don't understand that - this is an inner class of PluginApp. How
> can you access it directly via the entry point? But generally I
> understand the workflow.
The part after the : in the entrypoint is probably not used at all at
the moment. With the entry point, I get the Django app. Then, with the
Django app, I get the inner class from the app registry:
https://github.com/pretix/pretix/blob/0b167aaa2cf607adddf4fe96c3da55b160b95602/src/pretix/base/plugins.py#L24
> * How do you use signals? e.g.
>
> @receiver(footer_link, dispatch_uid="pages_footer_links")
> What does this mean? How do you pass this to your frontend? Could you
> describe this in just a few words?
These are basically standard Django signals, with only slight
modifications to be able to turn them off per-client:
https://docs.djangoproject.com/en/2.0/topics/signals/
I then use a few custom helpers like a custom template tag that allows
to call a signal directly from a template:
{% eventsignal event "path.to.signal" argument="value" ... %}
This is just to avoid repetitive code, however.
> I'd like to add channels to the mix as well to enable a Vue frontend.
> Instead of copying your code and forking the parts that I need, It
> would be better OpenSource practice to maybe build a "plugin system"
> that is a library and can be used of both - this is not very
> difficult IMHO, b'cause most of it is already there.
>
> Just tell me what you think about it - I can live with both - I just
> think that stability is better if more projects rely on one library
> and find security flaws and bugs alternatively ;-)
It would be great to have a library based on the ideas in pretix that
others can depend on. I'm not sure if pretix itself could use it, since
some of the things we do in the plugin API are very domain-specific,
like allowing plugin URLs to specify if they should be available only
when a shop is enabled or always.
A generic library would need to behave a bit different in design, and
changing that now will be hard for pretix, since there are already >50
plugins out there.
That said, I'd love to see it and maybe even collaborate on it!
> I have written a IMHO better plugin handler:
> https://gitlab.com/nerdocs/medux/MedUX/blob/develop/medux/extensionsystem/__init__.py
> …
> This way all plugins can just "implement" predefined Interfaces,
> supereasy.
I like it! It is more framework-agnostic than our approach and
therefore probably more flexible. Our approach is a bit more tied to
Django's internals and therefore makes some things easier, but some less
clean.
Best
Raphael
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/20180801093159.49fd646d%40tavi.localdomain.
For more options, visit https://groups.google.com/d/optout.
pgpUvNQYOfvvI.pgp
Description: Digitale Signatur von OpenPGP
