Hey everyone, I have a custom path converter DateConverter, that is used in different apps like ‘blog’ and ‘events’ across my project. DateConverter is itself defined in my ‘common’ app, that handles common functionality. I used to register the converter in all urls.py that used it, but I noticed that Django 5.1 deprecated overriding existing converters. Now I am wondering where I am suppose to register it. I feels weird to do it in root urlconf, because my project also are using django-hosts. I also thought about doing it in AppConfig’s ready() method in my ‘common’ app, but I am unsure if this is bad somehow.
Yes. You can still create new converters, but you are not supposed to replace existing converters. See the associated ticket and notes - #35090 (Enforce uniqueness on custom path converters) – Django
Can you explain why? The docs specifically recommend doing it there.
Given that these converters are used globally, I’m not sure why django-hosts would have an effect on this.
The docs says “Register custom converter classes in your URLconf using register_converter()”. I’m reading that as one should register the converter it in the app’s URLconf, not the root URLconf of the project.
Only one of the subdomains on my site uses the projects root urlconf, the other subdomains point to other urlconfs, as specified in the root hostconf. So it feels weird because it feels like I’m only defining the converter for one subdomain (even though I know it gets define globally.)
It doesn’t matter which file it’s in. The definition becomes a global resource, so you can place it in any urls.py file. (This is the primary reason why they should be globally unique.)
The term URLconf is effectively defined at the top of that page as being the set of all linked urls.py files.
To design URLs for an app, you create a Python module informally called a URLconf (URL configuration). This module is pure Python code and is a mapping between URL path expressions to Python functions (your views).
This mapping can be as short or as long as needed. It can reference other mappings. And, because it’s pure Python code, it can be constructed dynamically.
And, for completeness, I’ll point out that there’s no requirement anywhere within Django that URL definitions actually be stored in files named urls.py.
You could place it in your root hostconf. (Actually, if you really wanted to, you could place it in your settings.py file.)
Thanks you for your time and responses. 
I don’t get the feeling that there’s an obvious canonical way, to register a cross-app path converter. But doing it in a top-level URLconf, would be an appropiate place to do it.
And just because I could do something (like placing it in settings.py) doesn’t mean I should do it 
Oh, I agree totally there.
Find a place where you feel comfortable and put it there.
If you look at the source for register_converter, all it’s effectively doing is adding the converter to a module-level dict.
I guess the real point that I was trying to make is that it really just doesn’t matter much what file it’s in, as long as that file is imported during Django’s initialization process. You could even bury it in a models.py or views.py file. (I’d probably curse the person doing it if I ever found one there, but it could be done - such is Django’s flexibility in some areas.)
1 Like