I've made a PR to remove the options parameter:
https://github.com/django/django/pull/14542
On Wed, 9 Jun 2021 at 07:03, 'Sébastien Gélis' via Django developers
(Contributions to Django itself) <django-developers@googlegroups.com> wrote:
> > *The number of lines is not the most important factor. There is no
> point in adding a new feature without tests and docs, because without them
> we will add a feature only for a single user, i.e. for the reporter. Also,
> we cannot add features just because they are not complex ("death by a
> thousand cuts"), each of them has a maintenance cost. Moreover, adding new
> features to the admin which are not used by admin itself is quite
> controversial.*
>
> Totally agree with you on that. My point was therefore: let's either
> implement this feature fully or, as Adam later suggested, remove the
> options parameter.
>
> > *Django's policy for what is maintained and extensible as "public API"
> is only those things that have been documented. This is its "deprecation
> policy":
> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
> <https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy>
> . Since neither the function nor the parameter have been documented, no one
> should not rely on them. It's the same for an unused parameter in an
> internal Python function. We remove many such parameters in each Django
> version without deprecation.*
>
> Thanks for this important clarification. I'll refactor my code to use a
> totally custom JS then, and leave this undocumented autocomplete.js alone
> for good :-)
>
> > *If anything, your highlighting the parameter has made me think we
> could remove it.*
>
> Count me in favor of this + documenting how front-end overrides of
> autocomplete are expected to be done (complete override of autocomplete.js
> or custom version compatible with AutocompleteJsonView).
> Would be happy to push a commit in this direction.
>
> Thanks again to you guys for taking the time to lead me through this!
>
> Sébastien
>
> Le mardi 8 juin 2021 à 17:39:22 UTC+2, Adam Johnson a écrit :
>
>> I'd be happy to suggest longer versions (if technically possible to
>>> implement).
>>>
>>
>> At least the documentation for triaging tickets is here:
>> https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
>> .
>>
>> I do not understand why the $.fn.djangoAdminSelect2 function would
>>> accept an options parameter at all then. This options parameter is never
>>> used in Django's own code, as far as I can tell.
>>>
>>
>> This looks like an oversight in the original commit to add the function:
>> https://github.com/django/django/commit/94cd8efc50c717cd00244f4b2233f971a53b205e
>> . The parameter has indeed never been used by Django.
>>
>> Django's policy for what is maintained and extensible as "public API" is
>> only those things that have been documented. This is its "deprecation
>> policy":
>> https://docs.djangoproject.com/en/dev/internals/release-process/#internal-release-deprecation-policy
>> . Since neither the function nor the parameter have been documented, no one
>> should not rely on them. It's the same for an unused parameter in an
>> internal Python function. We remove many such parameters in each Django
>> version without deprecation.
>>
>> If anything, your highlighting the parameter has made me think we could
>> remove it.
>>
>> On Tue, 8 Jun 2021 at 15:55, Mariusz Felisiak <felisiak...@gmail.com>
>> wrote:
>>
>>> > Additionally, I do not see how this would add complexity to the code
>>> and/or the API. The API would remain strictly the same (
>>> $.fn.djangoAdminSelect2(options)) and the code itself needs only an
>>> additional ~5 lines.
>>>
>>> The number of lines is not the most important factor. There is no point
>>> in adding a new feature without tests and docs, because without them we
>>> will add a feature only for a single user, i.e. for the reporter. Also, we
>>> cannot add features just because they are not complex (*"death by a
>>> thousand cuts"*), each of them has a maintenance cost. Moreover, adding
>>> new features to the admin which are not used by admin itself is quite
>>> controversial.
>>>
>>> My 2 cents.
>>>
>>> Best,
>>> Mariusz
>>>
>>> --
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/07713c30-7d56-4f34-b802-8e4d3cfc2bc6n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/11f4a625-f80f-4b7a-b821-e40d0e7e9a5fn%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/11f4a625-f80f-4b7a-b821-e40d0e7e9a5fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM0AZrE2bc8C9f6GUYc_BTMwXwx46UgoY-5jm2Fknr_nVw%40mail.gmail.com.
