Opened 5 years ago

Closed 4 months ago

#18394 closed Cleanup/optimization (fixed)

Add warning for invalid JavaScriptCatalog 'packages'

Reported by: James Bennett Owned by: nobody
Component: Internationalization Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tim Graham)

The javascript_catalog i18n view's packages argument only accepts modules which are either django.conf or which are also in INSTALLED_APPS. But there are two issues with this:

  1. The documentation for the view hides this a bit, and can create the impression that the restriction only applies to a packages argument passed through the URL.
  1. The view itself does not give you any warning if you're violating this restriction; it just silently discards anything in packages that doesn't meet the requirements.

At the very least, the documentation should be more up-front that this requirement always applies no matter how you're passing packages to the view. Possibly as a bonus, the view should warn that it's discarding any packages that don't conform to the requirements, to aid in debugging.

Change History (12)

comment:1 Changed 5 years ago by Aymeric Augustin

Component: DocumentationInternationalization
Triage Stage: UnreviewedAccepted

Two problems are reported in this ticket:

(a) the documentation of javascript_catalog is confusing

(b) invalid package names are silently dropped: yes, silent failure is bad and we should do something. Raising an exception would be backwards incompatible. Raising a warning could be a good compromise.

I've created #18596 to track (a). Let's focus this ticket on (b).

comment:2 Changed 18 months ago by Tim Graham

Cc: Claude Paroz added
Description: modified (diff)

Claude, I know made some improvements when you created the new JavaScriptCatalog class-based view in 1.10. Is this ticket still relevant for that view?

comment:3 Changed 18 months ago by Claude Paroz

Yes, this is still relevant (now in JavaScriptCatalog.get_paths method).

comment:4 Changed 18 months ago by Tim Graham

Cc: Claude Paroz removed
Summary: Better docs, and possibly better handling, for 'packages' argument to javascript_catalogAdd warning for invalid JavaScriptCatalog 'packages'
Type: BugCleanup/optimization

comment:5 Changed 7 months ago by Claude Paroz

Has patch: set

comment:6 Changed 7 months ago by Tim Graham

Instead of a RuntimeWarning as proposed in the PR, would it make more sense to raise a deprecation warning and eventually error out (or even error out now)? I usually favor raising an error straight away, rather than delaying that notice with a deprecation path, if it reveals a mistake a developer made (a past case was QuerySet.select_related() validating the values it receives) but I'll defer a decision here since I'm not a JavaScriptCatalog user.

comment:7 Changed 7 months ago by Claude Paroz

Aymeric, would you like to develop about your backwards compatibility concerns?
Would erroring out be acceptable (considering a release note about that new behavior)?

comment:8 Changed 5 months ago by Aymeric Augustin

When I made this comment five years ago, I was learning to triage tickets and clearly I didn't know James... Don't take what I wrote too seriously!

I think raising an error and documenting the change is fine, since the code isn't working as intended anyway in that case.

comment:9 Changed 5 months ago by Claude Paroz

Patch needs improvement: set

Thanks for your input!

comment:10 Changed 5 months ago by Claude Paroz

Patch needs improvement: unset
Version: 1.4master

comment:11 Changed 4 months ago by Tim Graham

Triage Stage: AcceptedReady for checkin

comment:12 Changed 4 months ago by Claude Paroz <claude@…>

Resolution: fixed
Status: newclosed

In 23142eea:

Fixed #18394 -- Added error for invalid JavaScriptCatalog packages

Thanks Tim Graham for the review.

Note: See TracTickets for help on using tickets.
Back to Top