New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic registration of co-installed 3rd party library types #10

Open
mahmoud opened this Issue May 9, 2018 · 4 comments

Comments

Projects
None yet
2 participants
@mahmoud
Owner

mahmoud commented May 9, 2018

We already have a snippet documented for automatic Django ORM type iteration. Should this behavior happen automatically if glom and Django are in the same env?

If so, I think we may want to make an environment variable disabling this behavior, for those who wish to avoid the runtime import overhead. Right now glom.core depends on nothing but the stdlib and represents a very lightweight import. That won't stay true if it tries importing from a bunch of paths and either failing or loading large codebases that aren't even necessarily used. (see also: mahmoud/ashes#31)

@jpic

This comment has been minimized.

jpic commented May 10, 2018

If glom is in INSTALLED_APPS, then it will import the app in glom.default_app_config, for example with glom.default_app_config = 'glom.django.app.AppConfig' then this allows AppConfig to do the registration in ready().

https://docs.djangoproject.com/en/2.0/ref/applications/

@mahmoud

This comment has been minimized.

Owner

mahmoud commented May 10, 2018

@jpic that's some good detailed info! Interestingly that would involve making glom into a django app, even if not directly depending on django as an installation requirement. Am I understanding that correctly? Definitely worth a think, even if it doesn't answer the question for SQLAlchemy and other libraries with interesting types.

@jpic

This comment has been minimized.

jpic commented May 11, 2018

Well, there will be a conflict if another library that's not compatible with Django decides to use glom.default_app_config, load the module it contains as a string, and expect anything else than a Django App, otherwise, everything will be fine.
Otherwise, we could have a django app in glom/django_glom, then the user can add glom.django_glom to INSTALLED_APPS and benefit from auto registration with the App class, that could also autodiscover glom.py files from INSTALLED_APPS like Django already does for the admin or models.
Otherwise, you can move glom/ to src/glom and change the setup script to it install all modules from src/, then it will install src/glom_django, src/glom_sqlalchemy, etc ... you can see examples in yourlabs/django-autocomplete-light or yourlabs/crudlfap, their setup.py install all modules in src/ subdirectory which is great to keep control on depencency coupling.
But before SQLAlchemy I'd like to check if glom can support also Django Forms or WTForms library 😂
Let me know if you want me to propose a patch of one of the things i'm talking about ;)

@jpic

This comment has been minimized.

jpic commented May 11, 2018

Forgot to show example django app auto discovery for registration: https://github.com/yourlabs/crudlfap/blob/master/src/crudlfap/apps.py

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment