Am 16.06.19 um 10:06 schrieb Adam Johnson: > * Your “homepage” link on PyPI is example.com <http://example.com>. > The usual thing to do here is link to your source host or docs. Set > this as url in your setup.py. Sure. Forgot this when switching from setup.py to setup.cfg. Corrected, thanks. > * I see you list pretix as an inspiration - did you see Raphael have a > talk at Djangocon Europe in April on this? > https://youtu.be/QbitxAEEZjI It may be old news to you though if > you’re familiar
Didn't know this talk, thanks. But I had an email conversation with him a while ago about that and he was the one who I learned a lot from about how to create GDAPS. Basically my implementation does not differ too much, and I even am considering using his "PretixPluginMeta" inner class in the AppConfig of GDAPS plugins too. I just think about other ways ATM - but I'm pretty sure I'll implement his way - in a more generic style. It even could be that GDAPS plugins are so similar that Pretix *could* switch it's underlying plugin system to GDAPS without changing very much. He did a really great job there and I never would be able to do this on my own, without the insights he gave me to Pretix. Same goes for PyUtilib. > * GPL can make your project hard to use, because depending on the > lawyers it can be interpreted as having to make the website source > code public. In the one dependency audit I went through, GPL and AGPL > were disallowed and we had to strip a dependency or two because of this. Yes, you are right too. This was another too fast shot - I'd like to release my project which is using GDAPS under the GPL/AGPL later. GDAPS is a library, and here the GPL doesn't help much. I need to think about it a bit, a little part of the code is from PyUtilib (which is BSD), and a bit copied from Graphene-Django (which is MIT). So maybe I'll switch to BSD too. Recommendations here for Django libraries, or specially GDAPS? > * What do you think are the implications for Django core? Is there > anything Django could do better to support this and all the other > plugin systems you’ve looked at? Also I’m totally sure you can > contribute, it’s not scary and there is a lot of information on > getting started! See > https://docs.djangoproject.com/en/dev/internals/contributing/ Yes, I'll have a deeper look at the contributing guidelines. The most parts where I had to struggle within Django were: * The settings, to let each module provide it's own setting. There is no standardized way of having settings saved. I borrowed the graphene-django way - which had copied it from DRF ;-) * Django doesn't allow to easily add apps to the running server when already started. Even adding apps to INSTALLED_APPS after loading Django is impossible, it has to be done within the setup process - I solved that using a Pluginmanager method (find_plugins) which is called after declaring INSTALLED_APPS in settings.ps, and which returns an INSTALLED_APPS compatible array which can be merged into INSTALLED_APPS. This method is certainly not able to call DB commands in that early startup point of time. So what I initially planned, downloading apps from a connected "app store" for my application, installing it "on the fly" (including makemigrations/migrate paths) and hooking in the plugin into the running process is not possible in Django. I don't have a big problem here, as installing a plugin ATM in GDAPS is just (for projects without SPA/frontend support): stop server pip install fooplugin ./manage.py makemigrations ./manage.py migrate start server which is perfectly ok for what I need. * URL routing was easy to integrate - the only thing which is remaining IMHO is - django does not help to "weigh" the rules. But this is a thing I want to implement in GDAPS - to give plugin apps the possibility to add a "weight" to URL paths so they are "ordered" in a more deterministic way. I just created a ticket where I described that a bit: https://gitlab.com/nerdocs/gdaps/issues/4 Same could go to the INSTALLED_APPS ordering. A "weight" ordering is not ideal here, I think that a dependency resolution system would be much better here. Here Django could help a bit - Django apps are depending on other apps, declared in setup.py or setup.cfg. If this meta information would be available to Django (or GDAPS), the loading of apps (GDAPS plugins) could be at least done automatically in a way that dependant apps are loaded after their dependencies. So far... much to do. I hope earth is going to spin slower soon, so a day gets more than 24h. ;-) Christian -- 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/aba23fb4-1ab5-4ed1-b4c3-28068d7d50be%40nerdocs.at. For more options, visit https://groups.google.com/d/optout.
pEpkey.asc
Description: application/pgp-keys
