Django integration

[sanjioh]

Hi! and thanks for sharing this library with the community.

I was wondering if a Django integration would be feasible in the future. I think it would be very valuable for all the Django users out there forced to use monkeypatching to stub out service dependencies.

Thanks!

[hynek]

I think/hope it would absolutely be feasible, but I would need someone who's intimate with Django and its ecosystem/best practices to drive the design.

I don't want to speculatively implement something based on tutorials just to learn it's not something ppl do in production!

Fortunately, @seddonym and his colleague just promised me to help. 😇

---

One interesting point that kept coming up and that we never quite got out of the way is the position towards the ORM. Given how central it is, it probably shouldn't be treated as a regular service.

[sanjioh]

That's great news, thank you!
WRT to the ORM, I agree with you that it should be special cased as it's too integrated with django to be considered an external service.

My main pain point wrt services in django is external API clients - I think svcs would do wonders to have them implemented/accessed properly.

[seddonym]

Fortunately, @seddonym and his colleague just promised me to help.

'Promised' is putting it strongly, but maybe! My colleague is @samueljsb, looping him in.

[hynek]

Yes, I'm sorry the correct term is of course "took a blood oath". I apologize for the confusion!

[seddonym]

🩸

[hynek]

On a slightly more serious note: I do not expect anyone to open a PR with Django integration.

But I need to understand how it would be implemented properly such that the community doesn’t roll their eyes. With FastAPI and Starlette, I could take an educated guess and then ask for feedback from their maintainers.

Django is a different beast, so I’ll need help from the start.

[MarkusH]

This is the first thing that comes to mind:

The configuration of the svcs would happen through a settings variable in settings.py, e.g.

SVCS_CONFIGS = {
    "svc1": {
        "svc_type": "fully.qualified.python.path.to.Type",
        "factory": "fully.qualified.python.path.to.callable:or_method",
        "enter": bool,
        "ping": "fully.qualified.python.path.to.callable" or function,
    },
    ...
}

Then, in SvcsAppConfig(django.apps.AppConfig).ready(), you'd instantiate svcs' registry with all the service definitions from above.

[sanjioh]

AFAICT there is at least one example of imperative configuration in the django ecosystem, that is django-environ (see https://django-environ.readthedocs.io/en/latest/quickstart.html).

IMHO svcs would benefit from a similar approach, since a declarative-style configuration could become very verbose.

[seddonym]

there really no precedent for using proper classes etc to configure something in Django?

I don't believe there's anything stopping you as far as Django is concerned, but the reason why we don't, at least I've always assumed, is to reduce the number of modules that are imported at bootstrap time. So Django tends to specify things as strings in the settings file and only load them if it needs them.

But there are alternatives to configuring everything in the settings file. I'm inclined to agree with @hynek that it would be nicer to work with richer objects. Perhaps a better approach would be to just do it through INSTALLED_APPS (i.e. add scvcs and some_app to INSTALLED_APPS) and then leave everything else to custom python files, rather than in settings.py which probably should just be strings.

Django has a way of autoloading modules by name based on which apps are installed, in same way as it does with models.py. As @MarkusH suggests we would do that by making scvs itself a Django app and calling autodiscover_modules from the AppConfig.ready() method. It's straightforward.

I haven't played around with svcs enough yet to say exactly what would be in those discovered modules, but possibly a good name would be services.py?

myproject/
   some_app/
      __init__.py
      services.py  # Define service factories in here.

It would probably be sensible to provide the ability to configure a different name for autodiscovery just in case this clashes with existing names in a project.

[MarkusH]

@seddonym I completely forgot about module auto discovery. Yeah, create the registry in SvcsAppConfig().ready(). Afterwards, autodiscover all svcs modules in all installed apps.

[seddonym]

The alternative, if we think users will only want to configure it in a single place, is to have a setting where we specify the location of that module, e.g.

# settings.py

SVCS_CONFIG_MODULE = "myproject.services"

[hynek]

1. Thank you everyone for helping – this kind of creative ping pong is exactly what I was hoping for.
2. This is gonna be a lot harder than I thought! TBH, I'm starting to sense there's a non-0 chance I might punt on it and help making a Django-svcs happen. The complexity to make this properly sounds like it might compete with all of the complexity until now combined? 😅

Please keep it coming, this is awesome!

[offbyone]

Somewhat frustratingly, back-links to discussions aren't automatic.

I bodged together something that sort of looks okay here: WorldconVotingSystems/nomnom#132

Probably the one notable weird thing is that it allows a Container associated with the Settings themselves; this allowed me to use services registered in apps to configure things like middleware and other apps. In Django, that makes sense in the lifecycle (I think! I am not an expert!)

The actual uses of it in this PR are super minimal, but I'll toss it out here as an implementation that might work; I'm curious what y'all think.

[offbyone]

@hynek this is part of the outcome of my asking about global services.

[hynek]

JFTR,the current implementation can be found here: https://github.com/WorldconVotingSystems/nomnom/tree/main/django_svcs