来自管理界面的Django自定义管理命令 [英] Django custom management commands from admin interface

查看:128
本文介绍了来自管理界面的Django自定义管理命令的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我问过一个以前的获取django命令以便按计划运行的问题。我得到了一个解决方案的问题,但我仍然希望让我的命令从管理界面运行。我遇到的障碍是,一旦我进入管理界面,我的自定义管理命令就不会被识别。

I asked a previous question getting a django command to run on a schedule. I got a solution for that question, but I still want to get my commands to run from the admin interface. The obstacle I'm hitting is that my custom management commands aren't getting recognized once I get to the admin interface.

我将其追溯到 __ init __。py 文件的 django / core / management 实用程序。似乎有一些奇怪的行为。当服务器首次出现时,字典变量_commands将填充核心命令(从 django / core / management / commands )。来自所有已安装应用程序的自定义管理命令也被推入到所有管理命令的整体字典的_commands变量中。

I traced this back to the __init__.py file of the django/core/management utility. There seems to be some strange behavior going on. When the server first comes up, a dictionary variable _commands is populated with the core commands (from django/core/management/commands). Custom management commands from all of the installed apps are also pushed into the _commands variable for an overall dictionary of all management commands.

不知何故,虽然在服务器启动之间,当django-chronograph从管理界面运行作业时,_commands变量会丢失自定义命令;字典中唯一的命令是核心命令。我不知道为什么会这样。可能是路径问题吗?我错过了一些设置吗?这是一个django计时码表具体问题吗?所以忘了安排如何从django管理员图形界面运行自定义管理命令来证明它可以做到这一点?或者,如何确保从该界面可以使用自定义管理命令?

Somehow, though between when the server starts and when django-chronograph goes to run the job from the admin interface, the _commands variable loses the custom commands; the only commands in the dictionary are the core commands. I'm not sure why this is. Could it be a path issue? Am I missing some setting? Is it a django-chronograph specific problem? So forget scheduling. How might I run a custom management command from the django admin graphical interface to prove that it can indeed be done? Or rather, how can I make sure that custom management commands available from said interface?

推荐答案

我是 unix-guy上面提到的tom tom。

i am the "unix-guy" mentioned above by tom tom.

据我所知,在计时码本身中有一些问题,所以使用代码tom tom发表在评论中。

as far as i remember there were some issues in the cronograph code itself, so it would be a good idea to use the code tom tom posted in the comments.

文件系统中的哪里是django-cronograph存储的(在你的应用程序文件夹中,在一个额外的lib文件夹或你的

where on the filesystem is django-cronograph stored (in you app-folder, in an extra "lib-folder" or in your site-packages?

当您在site-packages或其他文件夹中的global pythonpath路径时,应该没有问题。

when you have it in site-packages or another folder that is in your "global pythonpath" pathing should be no issue.

cron进程本身不使用相同的pythonpath作为您的django应用程序。记住:您通过crontab启动cron进程 - 对吗?所以有两个不同的进程不知道对方:cron进程和django进程(由webserver初始化),所以我建议通过crontab调用以下脚本再次导出pythonpath:

the cron-process itself DOES NOT USE THE SAME pythonpath, as your django app. remember: you start the cron-process via your crontab - right? so there are 2 different process who do not "know" each other: the cron-process AND the django-process (initialized by the webserver) so i would suggest to call the following script via crontab and export pythonpath again:

#!/bin/bash

PYTHONPATH=/path/to/libs:/path/to/project_root:/path/to/other/libs/used/in/project
export PYTHONPATH

python /path/to/project/manage.py cron

所以cron-started-process与你的项目有相同的pythonpath信息。

so the cron-started-process has the same pythonpath-information as your project.

greez

berni

这篇关于来自管理界面的Django自定义管理命令的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆