Discussion regarding #32628 and #32823

[Sébastien Gélis]

Dear community,

I am writing to this group as a last resort and as advised (twice) by Mariusz Felisiak. I have several points to make.

1. Ticket #32823 is not a duplicate of #32628. #32628 was indeed a mixed bag but mostly a feature request including a bugfix. #32823 was an attempt to get the bug fixed ASAP while perhaps discussing the feature request made in #32628 separately. This, apparently, was not understood.

2. I understand that a feature request might be disregarded, but ignoring a bugfix with an offered PR is harder to understand for me.

3. Regarding the original feature request, I am disappointed that it got flagged as wontfix before I even had a chance to make my point and be understood. I later offered a slight rewrite of the autocomplete.js file that implemented the feature (and fixed the bug) in a way that could be accepted by Johannes Maron (not breaking Select2 API mirroring) but got no answer.

I understand that Django is a very large project and that you guys are all volunteering to this.  I (and my company) am definitely willing to offer developer time to help this project grow. But treating new-coming developers like you did is just discouraging (to say the least), at least for me.

So will you please consider at least discussing the issues I raise here?

Best regards,

Sébastien Gélis

[Carlton Gibson]

Hi Sébastien. 

Sorry you feel hard done by here. I think that's perhaps unfamiliarity with the workflow. As per the triage workflow that Mariusz pointed you to, this is the correct place to discuss tickets that are marked as wontfix. 

The reality is we have a constant firehose of new tickets and do not have the capacity to go back and forth multiple times on the same ticket on Trac. 

What is more, the audience on the mailing list here is much wider that that on the issue tracker, which is why it's better to discuss things here. 

We do try and point folks this way, but it's not always clear I guess. 

So... 

Having looked at the ticket, I agree with the initial assessment: 

First, #32628 is suggesting a new feature to allow customising the ajax request used in the admin autocomplete view. At first pass, that's out-of-scope — that's not something that we want to add options around — it's simply not worth the complexity. Options include overriding autocomplete.js yourself, or building a custom view, rather than trying to extend the admin beyond its core use-case. 

This ties into your point 3 here. The wontfix comes with several suggestions, both from Mariusz and Johannes — both suggesting overriding the JS file as the most likely way forward for you. 

Then, sorry but, #32823 is just a duplicate. There's no bug there, unless you're looking to extend the JS in exactly the way you asked for in the previous ticket. That the usage of the underlying library's API does not allow holding it in an out-of-scope manner is not a bug (for Django). I hope that makes sense. 

So, to the suggestion... 

New features generally need motivating. My suggestion then would be to implement the alternate autocomplete.js and then show what it allows. "It's THIS PARTICULAR CHANGE and it allow THAT PARTICULAR USAGE" is a lot more powerful as a suggestion. 

However, it's not likely — not impossible, but not likely — that feature suggestions to add complexity to the admin autocomplete functionality would be accepted. 

Rather, I'm inclined towards Mariusz' initial comment that resolving #29700 to better document the autocomplete view would resolve the issue. We could include there customising the autocomplete.js side of it — perhaps your use-case would make a great example? In general we'd much rather go that way, instead of adding more complexity to the core itself. The admin's role is not to be a general application development platform, and we couldn't maintain it if it were: often that means we have to say no to possible features. The maxim that, if you need those features then implement a custom view, is part of the secret to its long life. 

Hopefully that all makes sense too. 

tl;dr: If you really want to make the case for this, implement autocomplete.js, help resolve #29700, then show that even with that in place this feature is needed for something that would be widely beneficial. This thread is the correct place for that discussion. 

I hope that helps. 

Kind Regards,

Carlton

[Adam Johnson]

Sébastien - on your original post: you didn't provide any useful title or ticket links in your post. That may have stopped readers engaging on the list. No one knows ticket numbers, but some people will be interested when they see a post on "the admin autocomplete". Links would make it easy to catch up. More context makes it easy to engage.

 

Carlton: Sorry you feel hard done by here. I think that's perhaps unfamiliarity with the workflow.

I agree here that it can be down to unfamiliarity. But perhaps the default copy-paste messages the fellows use could have a little more empathy towards those who are unfamiliar. The majority of Trac users are only around for one ticket, or a few.

Mariusz wrote: "Please follow triaging guidelines with regards to wontfix tickets." The conciseness *can* be read as curt.

I suggest a reword to something like  "I appreciate you'd like to reopen the ticket, but please follow the triaging guidelines with regards to wontfix tickets and take this to the django-developers mailing list."

 

Carlton: The admin's role is not to be a general application development platform

💯 agree here. My gut reaction is the same. Most organizations who try to build their "back office" within the admin end up digging themselves into a bit of a hole with their customizations. Building your own pieces is normally a better approach when you need a certain level of customization.

Just yesterday I was advising a client who wanted some different autocomplete customizations. I also recommended trying django-select2, as Johannes wrote on the ticket ( https://code.djangoproject.com/ticket/32628#comment:5 ).

[Sébastien Gélis]

Thanks a lot for the kind answers.

But perhaps the default copy-paste messages the fellows use could have a little more empathy towards those who are unfamiliar. The majority of Trac users are only around for one ticket, or a few.

I agree with you Adam, my emotional perception of the messages I received may boil down to conciseness and formalism of the copy/paste (almost automatic) answer. However I totally understand the overwhelming load of tickets on the Trac team and the need to process them efficiently. I don't know Trac under the hood, but maybe longer "automatic" answers can be written down somewhere, that explain things more thoroughly and gently, especially to newcomers. Your rewording suggestion sounds like a good start. If you are willing to discuss the topic I'd be happy to suggest longer versions (if technically possible to implement).

Sébastien - on your original post: you didn't provide any useful title or ticket links in your post. That may have stopped readers engaging on the list. No one knows ticket numbers, but some people will be interested when they see a post on "the admin autocomplete". Links would make it easy to catch up. More context makes it easy to engage.

You're totally right. I feel stupid for not thinking of that in the first place. That will serve as a lesson for my future posts to this board, sorry.

----

Now about the issue itself.

I think I understand the underlying point here, being: the admin is not meant to please every possible user, and thus should not be bloated with every possible feature. I definitely understand the need for the admin (and Django itself for that matter) to stay generic and encourage overriding.

My understanding of this argument stops early though, as 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.

The very presence of this parameter led me to think that I (as a regular Django user) could use the $.fn.djangoAdminSelect2 function when extending the admin for my own needs. Using it made me feel that I got my back covered since I used Django's implementation of Select2 and would then benefit future code evolution, which would avoid breaking of my own code.

This is why I suggested that, since this parameter exists, it should be fully and correctly implemented. In its current state, it allows to provide any Select2 option except those nested under the ajax key. If Django calls to $.fn.djangoAdminSelect2 were to evolve in future versions, and provided, say, the Select2 tags option, it could break my own calls to $.fn.djangoAdminSelect2 that provided the tags option.

The current situation seems totally counter-intuitive to me. I would expect options to be either absent (telling me that, if I want to instantiate autocomplete widgets for my own needs then I'm on my own) OR, if present, to be fully usable (meaning that I could really provide it any Select2 option, since Johannes Maron suggested it should respect Select2 API).

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.

Overrides of back-end autocomplete views, though useful, do not solve the same usecases.

Thanks again for your answers.

Best regards,

Sébastien Gélis

[Mariusz Felisiak]

> 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

[Adam Johnson]

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.

--
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.

[Sébastien Gélis]

> 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 . 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

[Adam Johnson]

I've made a PR to remove the options parameter: https://github.com/django/django/pull/14542

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/11f4a625-f80f-4b7a-b821-e40d0e7e9a5fn%40googlegroups.com.