Code

Opened 7 years ago

Closed 6 years ago

Last modified 3 years ago

#5522 closed (fixed)

Move commands daily_cleanup, make-messages and compile-messages to django.core.management.commands

Reported by: jezdez Owned by: jezdez
Component: Core (Other) Version: master
Severity: Keywords: i18n session
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Since having a fairly solid, pluggable django-admin command I prepared a patch which moves the heavy lifting to django.core.management and is fully backwards compatible with the standalone tools daily_cleanup.py, make-messages.py, compile-messages.py and unique-messages.py in django/bin.

This introduces four new commands:

messagesmake, messagescompile, messagesunique, cleanup

where the latter is the new name for daily_cleanup.py. Docs included.

Attachments (7)

django-admin.diff (37.2 KB) - added by jezdez 7 years ago.
patch to move utilities in django/bin to django.core.management
django-admin.2.diff (36.5 KB) - added by jezdez 6 years ago.
second patch to move utilities in django/bin to django.core.management
django-admin.3.diff (36.1 KB) - added by jezdez 6 years ago.
normal patch with SVN on fresh checkout (r7140)
django-admin.4.diff (36.8 KB) - added by jezdez 6 years ago.
makemessages and compileessages should now work in the svn root either by running django-admin.py * or bin/*.py without asking for DJANGO_SETTINGS_MODULE
django-admin.5.diff (38.7 KB) - added by jezdez 6 years ago.
As with Jacob discussed this patch moves the i18n helper functions to their appropriate subcommands and also includes [7473].
django-admin.6.diff (39.8 KB) - added by jezdez 6 years ago.
Added New in Django development version flags and notes about the old tools make-messages.py and compile-messages.py.
django-admin.7.diff (39.9 KB) - added by jezdez 6 years ago.
Raising CommandError instead of hard sys.exit in django.core.management.commands.makemessages:make_messages()

Download all attachments as: .zip

Change History (33)

Changed 7 years ago by jezdez

patch to move utilities in django/bin to django.core.management

comment:1 Changed 7 years ago by jezdez

  • Keywords session, sprintsept14 added; session removed
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 7 years ago by ubernostrum

  • Triage Stage changed from Unreviewed to Design decision needed

comment:3 Changed 6 years ago by mtredinnick

Possibly worth it for make-messages and compile-messages (the reason in favour of it is that we need to rename those two programs anyway so that they can be installed in /usr/bin/ and using django-admin.py as the controller means we can handle settings more easily). Not needed for daily_cleanup, since that's very lightweight and this makes it less so. unique-messages.py isn't meant to be called directly, so that shouldn't be exposed.

comment:4 Changed 6 years ago by jezdez

Ok, fair enough.. I'd like to point out, that the creation of command line programs can be automated during installation with setuptools' "console_scripts" entry_point. I described a simple example at http://jannisleidel.com/2007/11/using-django-with-setuptools/ if you are interested. Though I know that there is more about setuptools which should be discussed :)

I'd like to provide a patch during the sprint (later today) which adds app-loading from eggs using pkg_resources. I would be glad if this would be added, since my GSoC approach (#5465) isn't very satisfying.

comment:5 Changed 6 years ago by mtredinnick

At no point here have you explained why all this moving is needed. Setuptool has nothing to do with it; it's a completely orthogonal issue and not relevant here.

comment:6 Changed 6 years ago by jezdez

Indeed, setuptools is not an issue here. Moving the code might be a good way to go on with the refactoring of command.core.management. I thought this could be another step towards a future "django" command line programm.

comment:7 Changed 6 years ago by jezdez

  • Keywords sprintdec01 added; sprintsept14 removed

comment:8 Changed 6 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

Let's do this, but only for make-messages, compile-messages, and daily_cleanup (but I'd rename that to "django-admin cleanup"). unique-messages is an internal tool, and shouldn't be exposed in django-admin.

Make sure to document the new commands!

comment:9 Changed 6 years ago by jezdez

Yeah, I'll work on it later today.

Changed 6 years ago by jezdez

second patch to move utilities in django/bin to django.core.management

comment:10 follow-up: Changed 6 years ago by jezdez

Ok, new patch (from mercurial clone) without unique-messages and docs (docs, manpage, bash_completion).

comment:11 in reply to: ↑ 10 Changed 6 years ago by jezdez

Replying to jezdez:

Ok, new patch (from mercurial clone) without unique-messages and docs (docs, manpage, bash_completion).

I mean *with* documentation

comment:12 Changed 6 years ago by SmileyChris

Can someone do a normal patch on a fresh Django SVN and confirm each command works as expected?

comment:13 Changed 6 years ago by jezdez

Already working on it :)

Changed 6 years ago by jezdez

normal patch with SVN on fresh checkout (r7140)

comment:14 Changed 6 years ago by SmileyChris

  • Triage Stage changed from Accepted to Ready for checkin

comment:15 Changed 6 years ago by jezdez

  • Summary changed from Move daily_cleanup, make-messages, compile-messages and unique-messages to django.core.management.commands to Move commands daily_cleanup, make-messages and compile-messages to django.core.management.commands

comment:16 Changed 6 years ago by mtredinnick

  • Patch needs improvement set
  • Triage Stage changed from Ready for checkin to Accepted

This doesn't seem to work. I applied the patch and tried to run bin/make-messages.py -l en and it complains about missing settings file. Similarly for django/bin/make-messages.py -l en and various places running django-admin.py messagesmake -l en.

Since there is no concept of a settings file for the subversion tree, this isn't really a replacement for existing functionality.

Also, can you rename messagesmake to makemessages and messagescompile to compilemessages for consistency with the existing names, please.

Changed 6 years ago by jezdez

makemessages and compileessages should now work in the svn root either by running django-admin.py * or bin/*.py without asking for DJANGO_SETTINGS_MODULE

Changed 6 years ago by jezdez

As with Jacob discussed this patch moves the i18n helper functions to their appropriate subcommands and also includes [7473].

Changed 6 years ago by jezdez

Added New in Django development version flags and notes about the old tools make-messages.py and compile-messages.py.

comment:17 Changed 6 years ago by ramiro

Shouldn't (for consistency with the rest of the management infrastructure) all the sys.exit() calls from the django/core/management/commands/makemessages.py:make_messages() function be replaced by raising the [source:django/trunk/django/core/management/base.py CommandError exception]?

If so, this means that the backwards-compatibility make-messages script would also need to be be modified accordingly.

Changed 6 years ago by jezdez

Raising CommandError instead of hard sys.exit in django.core.management.commands.makemessages:make_messages()

comment:18 Changed 6 years ago by jezdez

  • Triage Stage changed from Accepted to Ready for checkin

comment:19 Changed 6 years ago by jezdez

  • milestone set to 1.0 alpha

FYI, I changed it to "Ready for checkin" after the definite word by Jacob in IRC

comment:20 Changed 6 years ago by jezdez

  • Status changed from new to assigned

comment:21 Changed 6 years ago by garcia_marc

  • Keywords i18n session added; i18n, session, sprintdec01 removed
  • milestone changed from 1.0 alpha to post-1.0

According to ticket organization defined in http://code.djangoproject.com/wiki/VersionOneRoadmap#how-you-can-help 1.0 alpha tickets should be just features in the Must have (http://code.djangoproject.com/wiki/VersionOneRoadmap#must-have-features) list.

Change to 1.0 beta if you can make this feature be added to May be features (http://code.djangoproject.com/wiki/VersionOneRoadmap#maybe-features).

comment:22 Changed 6 years ago by jezdez

  • milestone changed from post-1.0 to 1.0 beta

I appreciate your care but this was already discussed in IRC with Jacob and others to be included in Django 1.0.

comment:23 Changed 6 years ago by mtredinnick

Good work. I've decided to actually remove the dual functionality from make-messages.py and compile-messages.py. Otherwise we'll be carrying around two ways to do the same thing forever. Instead both those executables now print an error message pointing the caller to the right command to run. I've updated the docs patch accordingly.

comment:24 Changed 6 years ago by mtredinnick

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [7844]) Fixed #5522 -- Moved make-messages, compile-messages and daily-cleanup into django-admin.py.

They are now called "makemessages", "compilemessages" and "cleanup". This is
backwards incompatible for make-messages.py and compile-messages.py, although
the old executables still exist for now and print an error pointing the caller
to the right command to call.

This reduces the number of binaries and man pages Django needs to install.

Patch from Janis Leidel.

comment:25 Changed 6 years ago by mtredinnick

Community Announcement: if anybody notices errors in this change, please do not reopen this ticket. This ticket is about making the move, which has been done. Errors in the resulting code should have their own tickets so that we can track things easily.

comment:26 Changed 3 years ago by jacob

  • milestone 1.0 beta deleted

Milestone 1.0 beta deleted

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.