niceban / django-command-extensions Goto Github PK

A django admin command that takes a fixture and makes the target database
the same as that fixture, deleting objects that in the database but not in
the fixture, updating objects that are different in the database, and
inserting missing ones.

http://www.djangosnippets.org/snippets/926/

would be great if that would be possible. then one could easily check if
login_required is activated on all the right views.

just trying to get the png file for my model, but I got this exception:

IOError: [Errno 36] File name too long: u'digraph name {   fontname = 
"Helvetica

using this command:
    python manage.py graph_models -a -g -o my_project_visualized.png

don't know if is something important or just my mistake!

What steps will reproduce the problem?
1. Use UUID Field in a model with lastest trunk verison of django

The field arg should be max_length not maxlength, see patch attached

see: http://code.djangoproject.com/ticket/7563#preview

By the time that 1.0 lands, some commands may have become useless or
included into Django itself.

It will be good for Django-extensions to follow Django releases closely and
remove clutter that's been building up from older releases.

This was requested by a friend who is a Mac fanatic, and would like to
import the django users into the address book.

This should be easy to do with the python module for vCard, but I have no
experience with it (nor a good means of testing).

It would be nice to allow an optional parameter to set the parent path.

Patch attached.

What steps will reproduce the problem?
1. Using python 2.3, run ./manage.py graph_models -a

What is the expected output? What do you see instead?
16:30:09[wlcg]lxvm0304.c$./manage.py  graph_models -a
Traceback (most recent call last):
  File "./manage.py", line 11, in ?
    execute_manager(settings)
  File
"/usr/lib/python2.3/site-packages/django/core/management/__init__.py", line
272, in execute_manager
    utility.execute()
  File
"/usr/lib/python2.3/site-packages/django/core/management/__init__.py", line
219, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/usr/lib/python2.3/site-packages/django/core/management/base.py",
line 72, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/usr/lib/python2.3/site-packages/django/core/management/base.py",
line 86, in execute
    output = self.handle(*args, **options)
  File
"/usr/lib/python2.3/site-packages/extensions/management/commands/graph_models.py
",
line 30, in handle
    dotdata = generate_dot(args, **options)
  File
"/usr/lib/python2.3/site-packages/extensions/management/modelviz.py", line
163, in generate_dot
    graph = Context({
AttributeError: 'str' object has no attribute 'rsplit'



What version of the product are you using? On what operating system?
0.4_pre (svn revision 77)
Python 2.3.4 - Scientific Linux 4 (RHEL4 compatible)

Please provide any additional information below.

Patch attached.

The new feature in Django 1.0 that allows explicit intemediate join tables,
and therefore relationship attributes, has a different API to a standard
many to many field.

This means that when dumpscript adds such a line for a Many-to-many field
with intermediate join model:
    my_object.things.add(other_object)
it will fail.

The simple solution is to simply remove this line, because the intermediate
table is a standard table and the relationship objects will be added anyway.

If you can work out which fields require this.

This patch aims to incorporate the changes to modelviz.py at
http://code.djangoproject.com/attachment/wiki/DjangoGraphviz/modelviz.5.py.

I imagine this is an issue no one wants to hear, but I'm a bit concerned
that "extensions" as a package name is far too broad a claim on the python
namespace landscape.

I'd like to propose djext as an alternative package name. A crude grep of
the source tree shows only 15 references to the "extensions" package name
in the package itself, and there are 4 more in setup.py.

If people don't want to burn my username in effigy, I'll gladly help.

What steps will reproduce the problem?
1.1 ./manage.py graph_models -a -o test.png
1.2 ./manage.py graph_models -o test.png my_app
2. Segmentation fault...

What is the expected output? What do you see instead?
The PNG for one or all apps, but I receive this output:

{{{
 syntax error in line 1 near '&'
Segmentation fault
}}}

What version of the product are you using? On what operating system?
* Ubuntu 8.04
* Python 2.5 and 2.4
* Django 0.97-pre-SVN-7554
* graphviz 2.16-3ubuntu2
* python-pygraphviz 0.35.dfsg-1ubuntu1

Please provide any additional information below.
The problem occurs only with --output parameter. With the command below
(only `dot` output) works fine:

{{{
./manage.py graph_models -a 
}}}

Thanks!

What steps will reproduce the problem?
1. run manage.py sqldiff on latest trunk

Expected: 
printed sqldiffs

Output:

  File
"D:\Python25\Scripts\g\..\g\apps\django_extensions\management\commands\sqldiff.p
y",
line 53, in handle_diff

    from django.db import models, connection, get_introspection_module
ImportError: cannot import name get_introspection_module

After deleting import get_introspection_module and changing
get_introspection_module to connection.introspection see
http://code.djangoproject.com/changeset/8296 or
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

I've got next problem:

  File
"D:\Python25\Scripts\g\..\g\apps\django_extensions\management\commands\sqldiff.p
y",
line 62, in handle_diff

    django_tables =
_sql.django_table_list(only_existing=options.get('only_existing', True))
AttributeError: 'module' object has no attribute 'django_table_list'

What version of the product are you using? On what operating system?
Python 2.5 on Windows XP SP3, Django latest trunk 1.0-alpha_2-SVN-unknown

Hi all

I noticed the sqldiff command today I thought it would be easy to plug a
--output-sql option to it, attached file is a patch that add this
functionality.

Notes : 
-The patch is quite long since I've moved some of the code around.
-I think it will be necessary to re factor a bit, I thought of a
--commit--change--and--yes--Im--sure option, that would imply a method that
returns the SQL as plain text (without styles), and the current code is not
able to do that.
-Maybe separating the retrieval of table_name, att_name, db_field_type,
model_type, and field and the actual output (be it fulltext or sql) would
be a good start
-I suck at naming function, properties, key etc...

If we have the following model setup:

    news/models.py:
        class Image(modes.Model):
            ...
    gallery/models.py:
        class  Image(models.Model):
             ...

and use ManyToMany, Foreign Keys etc the graph that gets produced will
think that that both image models are the same in effect hidding one of
them and producing incorrect relations.

Attached is a quick'n'dirty patch that solved the issue for me. All the
patch does is use to prefix the nodes with __module__ and update the
relations in the same way so that dot can distinguish the models with the
same names.

Although I have commit bits for the extensions I was not sure if you guys want 
to move on so fast. 
Anyway, the attached patch should add support for it, so I would be glad to 
hear if I can apply it.

Thanks and cheers

Create a new_secret_key command that will generate a SECRET_KEY for a project 
settings file.

What steps will reproduce the problem?
1. Create a app with GenericRelation from
`django.contrib.contenttypes.generic`; [models in attachment]
2. Generate the dot file from app; [./manage.py graph_models app_test >
test.dot]
3. Convert to PNG. [dot test.dot -Tpng -o test.png]

What is the expected output? What do you see instead?
I have this error output:

{{
Error: test.dot:102: syntax error near line 102
context:     [label="generic_test"] >>>  [style=& <<< quot;dotted&quot;]
[arrowhead=normal arrowtail=normal];
}}

The PNG and dot file are attachments.

What version of the product are you using? On what operating system?
* Ubuntu 8.04
* Python 2.5 and 2.4
* Django 0.97-pre-SVN-7554
* graphviz 2.16-3ubuntu2
* python-pygraphviz 0.35.dfsg-1ubuntu1

Please provide any additional information below.
Thanks!

current routine for finding the module namespace is broken and error prone

What steps will reproduce the problem?
1. Create model with textfield which contains UTF-8 symbols (for example
cyrillic). Add there text, for example hello in russian: 'Привет'
2. run manage.py shell_plus
3. MyModel.objects.all() returns model fields. Text there is displayed like
pseudo-graphic symbols. You should see the same you entered in step 1.

What is the expected output? What do you see instead?
Regular cyrillic symbols in text fields. Pseudo-graphic symbols

What version of the product are you using? On what operating system?
latest SVN on Windows XP SP2, Python 2.5.1

Please provide any additional information below.
All textfields contains cyrillic symbols in UTF-8 format. Regular shell
display cyrillic symbols without any problems.

What steps will reproduce the problem?
1. create a model that uses django-multilingual
2. run ./manage.py shell_plus

I get:
From 'auth' autoloaded: Message, Group, User, Permission
From 'contenttypes' autoloaded: ContentType
From 'sessions' autoloaded: Session
From 'sites' autoloaded: Site
From 'flatpages' autoloaded: FlatPage
From 'admin' autoloaded: LogEntry
From 'markup' autoloaded: 
From 'thumbnail' autoloaded: 
From 'auction' autoloaded: Building, Image, Apartment
From 'gallery' autoloaded: Image, Group
From 'multilingual' autoloaded: 
From 'menu' autoloaded: MenuItem, MenuItemTranslation
Traceback (most recent call last):
  File "./manage.py", line 12, in <module>
    execute_manager(settings)
  File "/opt/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 272, 
in execute_manager
    utility.execute()
  File "/opt/local/lib/python2.5/site-packages/django/core/management/__init__.py", line 219, 
in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/opt/local/lib/python2.5/site-packages/django/core/management/base.py", line 72, in 
run_from_argv
    self.execute(*args, **options.__dict__)
  File "/opt/local/lib/python2.5/site-packages/django/core/management/base.py", line 86, in 
execute
    output = self.handle(*args, **options)
  File "/opt/local/lib/python2.5/site-packages/django/core/management/base.py", line 168, in 
handle
    return self.handle_noargs(**options)
  File "/opt/local/lib/python2.5/site-
packages/extensions/management/commands/shell_plus.py", line 64, in 
handle_noargs
    imported_objects[model.__name__] = getattr(__import__(app_mod.__name__, {}, {}, 
model.__name__), model.__name__)
AttributeError: 'module' object has no attribute 'MenuItemTranslation'


I'm using svn trunk (revision 43).

django-multilingual creates an additional [ModelName]Translation model for each 
model that 
uses multilingual content. So shell_plus tries to import it but cannot find it 
because it actually 
does not exist in code.

If the user being printed has unicode characters for their first/last/or
user names, then the command will crash with an encoding error (if the
default DB encoding is not UTF8 or ASCII). This is because it uses the
'print' statement. We should be attempting to safe encode the strings
before printing.

There are other issues out of our control if the user has the wrong locale
or font set for the shell, but that is not our problem. 

Seems that there has been an update on the django trunk which is not
compatible with the written code in this file (daily_cleanup.py).

Maybe an option is just to use the normal cleanup from the django
extensions or call it from this file in order to be able to call other
features in the future.

What steps will reproduce the problem?
1. Create two django apps with namespace packages, using the same
namespace. (Easiest way is to easy_install ZopeSkel, then paster create -t
basic_namespace). Let's say you create foo.bar and foo.baz.
2. Put foo.bar and foo.baz somewhere on your pythonpath (say in
site-packages). You should have paths like
$PYTHONPATH/foo.bar/foo/bar/models.py.
3. Add a .pth file in your site-packages so python can load them. In the
above example, you might have a foo.pth containing:
./foo.bar
./foo.baz
4. Create a Django project, and put foo.bar and foo.baz in the INSTALLED_APPS.
5. Run python manage.py create_jobs baz. (If that appears to work, then try
create_jobs bar - it depends what your search path is as to which one will
error)

One of the above will give an ImportError. This is happening because
create_jobs.py iteratively walks the path of the located app, trying to
figure its directory out. It just uses the first one returned by
find_module. If we're trying to find foo.baz, for exmaple, and the first
module found happens to be that for foo.bar, site-packages/foo.bar/foo/
will eventually wind up as the app_dir. ImportError will then be raised
when the script tries to import 'baz' from that path.

I've attached a patch against r83 which works around this. There could be a
nicer way of doing this, but it works for me (as they say).




What version of the product are you using? On what operating system?


Please provide any additional information below.

this is more or less a follow-up patch from the '--all-applications' patch.

it adds several options to the graph_models command to directly create an
image of the graph using the pygraphviz bindings.

{{{
./manage.py graph_models -a -o myproject_all_models.png
}}}

or

{{{
./manage.py graph_models -a -l circo -o myproject_all_models.png
}}}

To use the circular layout for generating the graph.

Following Peter Sheats' wonderful idea of autoloading the models in the shell I 
implemented this 
new command "shell_with_models". Patch included. Please feel free to change the 
name of the 
command :)

The reset_db command extension from snippet 828 at djangosnippets.org is
handy, and it'd be convenient to have it packaged up in
django-command-extensions.  I've tried it and it works fine.  Patch attached.

i've included a patch to this issue, which adds the '-a' of
--all-applications option to the graph_models command.

v.oostveen left me a comment suggesting django-command-extensions might be an 
appropriate 
place for my syntax highlighting template filter [1] to live, so here is my 
attempt at an appropriate 
patch. Let me know if it should be reworked to better fit with the project's 
design (or anything else 
that I could do to help with its incorporation).


[1]: 
http://lethain.com/entry/2008/aug/09/a-syntax-coloring-template-filter-for-djang
o/

more a todo note then a real issue :)

current jobs system works and provides a pretty good solution for (simple)
job scheduling, but it uses a lot of copy-pastes code from django (which is
dirty) and some people would like to have more extensive scheduling.

the rewrite will/should be fully backwords compatibily in terms of jobs
classes.

I use the svn revision 2 on debian linux.

I get this output, when i have a many to many field in the model:

channel =
forms.ModelMultipleChoiceField(help_text=<django.utils.functional.__proxy__
object at 0xb74be92c>, required=False, label=u'Channel') 

What steps will reproduce the problem?
1. Using Werkzeug 0.2 cann't run latest SVN django-command-extensions
runserver_plus on WinXP (Python 2.5.2)

N:\src\...>manage.py runserver_plus
Validating models...
0 errors found

Django version 0.97-newforms-admin-SVN-unknown, using settings 'fobs.settings'
Development server is running at http://127.0.0.1:8000/
Using the Werkzeug debugger (http://werkzeug.pocoo.org/)
Quit the server with CTRL-BREAK.
Traceback (most recent call last):
  File "N:\src\...\manage.py", line 11, in <module>
    execute_manager(settings)
  File "E:\Python25\Lib\site-packages\django\core\management\__init__.py",
line 272, in execute_manager
    utility.execute()
  File "E:\Python25\Lib\site-packages\django\core\management\__init__.py",
line 219, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "E:\Python25\Lib\site-packages\django\core\management\base.py", line
72, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "E:\Python25\Lib\site-packages\django\core\management\base.py", line
86, in execute
    output = self.handle(*args, **options)
  File
"e:\python25\lib\site-packages\extensions\management\commands\runserver_plus.py"
,
line 68, in handle
    inner_run()
  File
"e:\python25\lib\site-packages\extensions\management\commands\runserver_plus.py"
,
line 67, in inner_run
    use_reloader=use_reloader, use_debugger=True)
TypeError: run_simple() got an unexpected keyword argument 'use_debugger'

Please provide any additional information below.

It seems that this is because of version inconsistence between Werkzeug on
my machine and used by command-extensions.

Removing "use_debugger=True" from run_simple() call arguments list solved
the problem.

Thanks.

Dumpscript handles generic relations by dumping out the values of the
contenttype and object_id fields directly.  Since objects created by
running a dumped script may well have a different autonumber PK, this means
that in many cases generic relations will be pointing to the wrong object
after running a dumped script.

The robust solution, it would seem, would be for a dumped script to assign
the proper object directly to the GenericRelation attribute rather than to
the contenttype and object_id fields.

What steps will reproduce the problem?
1. Create a class with a __call__ method.
2. Create a URL which maps to an instance of that class.
3. Run ./manage.py show_urls.

What is the expected output? What do you see instead?
You might want to try something like /some/url/ some.app.<Foo instance> if
it has no name.
Instead I get an AttributeError telling me my class instance has no
__name__ attribute.

What version of the product are you using? On what operating system?
0.2, ubuntu hardy

The disable_fields option of graph_models doesn't works. In attachment have
a patch that fixes the problem and remove trailing whitespaces.

remove createsuperuser because now Django supports this in trunk.

(possibly wrap this checking the django version / revision number to allow
use of the command-extensions version on older versions of django)

What steps will reproduce the problem?
1. Upgrade django trunk to r7722 or higher
2. Check out current trunk of django-command-extensions
2. Run ./manage.py dumpscript <appname>

What is the expected output? What do you see instead?

Should dump a Python-script version of the data in app <appname>.  Instead
raises an AttributeError: 'dict' object has no attribute 'add'

r7722 made seen_objs in _collect_sub_objects an instance of a
CollectedObjects class instead of a dictionary, and relies on the add()
method of CollectedObjects which a dict does not have.  dumpscript.py still
calls _collect_sub_objects() with a dictionary for the seen_objs argument.

From the last trunk of django, are a missing import module on the File
extensions/management/modelviz.py, line 45.

To correct:
./extensions/management/modelviz.py
45: #from django.utils.encoding import mark_safe
46: from django.utils.safestring import mark_safe

create_jobs always creates the jobs template directory under <project
dir>/<app name>/jobs.

Added a simple patch to fix this.

as shown in Eric Holschers excellent screencast: 

http://ericholscher.com/blog/2008/sep/12/screencast-django-command-extensions/

the describe_form output prints the repr() of a string proxy instead of the
string contents.

(should be a very easy fix)

I hope to get around to this in the next couple of days.
otherwise patches are welcomed :)

(p.s. if ur new to django and/or python and want to help, this might be an
issue for you to fix, as it's easy enough for a beginner, but will at the
same time require you to learn some of the django internals)

It's the Ghost of Namespaces Yet To Be, again.  ;-)

Not that I don't love all django command extensions dearly, but many of my
projects don't need all of them at once.  Other users may find their own
personal reasons for wanting to cherry-pick extensions, so I'd like to
suggest a compromise:

'django_extensions' in INSTALLED_APPS includes all jobs commands (hooray,
no backwards-incompatible changes like *other* issues I bring up)

'django_extensions.jobs' in INSTALLED_APPS would include only create_jobs,
runjob, and runjobs (plus maybe runscript, if you swing that way)

...etc.

Thoughts?
Jason

p.s. I know django_extensions.jobs won't do for technical reasons.

I'll just post this out of interest, in case parts of it may be useful.

It's a task/job scheduler that uses a django model to store information
about tasks and synchronises itself with crontab. So, you only need to
administer the django model (using admin or your own forms/views) and the
crontab will be updated and the tasks performed.

It was written for a specific project and so wider applications will need
to consider portability and security. For example, updating the crontab
simply uses system commands eg "crontab -l > %s". But the app is very
small, and has lots of tests, so I'm sure that if someone finds it useful,
they can easily check if their resulting site is secure.

Cheers,

Will

"python setup.py sdist" does not properly catch the template files in
extensions.conf.*.  The setup.py script itself is pretty hairy and
unreadable, making use of features of the Django setup.py script that do
not apply (particularly a roundabout method of capturing data files that
apparently doesn't work).

The attached MANIFEST.in (which should be in the same directory as
setup.py) makes sure that the *.tmpl files in extensions.conf are packaged.

Strictly speaking, the MANIFEST.in is all you need to get proper sdist
behavior on python 2.5 (and probably 2.4, though I haven't checked). 
However...

The attached replacement setup.py is not backwards-compatible to 2.3 (it
requires 2.4), but it accomplishes the same thing as the original script
with more clarity: the old script required more lines of code to find paths
automatically than there were paths to be found.

I touched-up the internal distribution name (which is independent of the
package name) from extensions to django-command-extensions.  This causes
setup.py sdist to create django-command-extensions-0.4_pre.tar.gz instead
of extensions-0.4_pre.tar.gz, and it affects various bits of metadata that
no one probably cares about anyway.

I tested the setup.py script against 2.4 and 2.5.  The MANIFEST.in *might*
DTRT on 2.3, but I don't have the means to check handy.

systems running on MySQL will use 1 and 0 for True and False, which wont be
accepted by other databases on import (such as postgres).

The value should be cast as a boolean value.

It would be nice to be able to specify individual models directly, eg

./manage.py dumpscript myapp.MyModel

Here is a dumpscript command I wrote, I had to refactor it to make it play
nicely with subclassing in queryset-refactor, but I developed it against a
test database using every field I could imagine.

There will probably certainly be teething problems, as I haven't used the
refactored version very much yet.

ContentTypes objects are not automatically included, but if you add the
contenttype app to the command line, it should add them. I will add a
special case for them later, it shouldn't be too hard.

This works nicely alongside the runscript command I found somewhere (I
didn't write it so I wont post it here).

Here is how it all works:

$ mkdir scripts
$ ./manage.py dumpscript myapp > scripts/populate.py
$ ./manage.py reset myapp
$ ./manage.py runscript populate

Of course you might want to inspect the script before resetting your app :)

Cheers,

Will

show_urls.py is trying to import from admindocs, which appears to be a 
newforms-admin 
contribution. I replaced the import line with the following and was up and 
running:

    try:
        from django.contrib.admindocs.views import extract_views_from_urlpatterns, simplify_regex
    except ImportError:
        from django.contrib.admin.views.doc import extract_views_from_urlpatterns, simplify_regex

It might be obvious but I'm rather slow today... ;-)