Skip to content
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
Open

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

mahmoud opened this issue May 9, 2018 · 4 comments

Comments

@mahmoud
Copy link
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
Copy link

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
Copy link
Owner Author

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
Copy link

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
Copy link

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants