admin commands
James Casbon
I have the following proposal to rectify the concerns Dorian had about
the management commands in HEAD. I think there are four ways to run
codenode:
1. Desktop version
2. Website/Production version
3. Development
4. Django App (similar to 2)
There are also four managment command locations:
1. Twisted commands
2. Django commands
3. codenode-admin
4. shell scripts in devel
I think I was probably wrong to move the server commands to Django.
These should live as twisted commands and be called by codenode-admin.
The only custom django command needed at the minute is to bootstrap
the database for a desktop or development environment. We should also
offer a command for this in codenode admin.
The part in codenode admin that needs to be fixed is how it picks up
the environment. If this was more flexible, I'm sure all the shell
scripts could well be moved into codenode-admin so that they are more
obvious along with everything necessary to run it as django app as
well.
If everyone is happy with this proposal I will cook up a patch with
documentation for the four ways to run codenode.
James
Dorian Raymer
Hi James,
Hi everyone,
I have the following proposal to rectify the concerns Dorian had about
the management commands in HEAD. I think there are four ways to run
codenode:
1. Desktop version
2. Website/Production version
3. Development
4. Django App (similar to 2)
There are also four managment command locations:
1. Twisted commands
2. Django commands
3. codenode-admin
4. shell scripts in devel
I think I was probably wrong to move the server commands to Django.
These should live as twisted commands and be called by codenode-admin.
The only custom django command needed at the minute is to bootstrap
the database for a desktop or development environment. We should also
offer a command for this in codenode admin.
The part in codenode admin that needs to be fixed is how it picks up
the environment. If this was more flexible, I'm sure all the shell
scripts could well be moved into codenode-admin so that they are more
obvious along with everything necessary to run it as django app as
well.
If everyone is happy with this proposal I will cook up a patch with
documentation for the four ways to run codenode.
James
--
http://groups.google.com/group/codenode-devel?hl=en
http://codenode.org
James Casbon
have a look at:
http://github.com/jamescasbon/codenode/commit/abf975a770f6b4982b648a7c10324535cbaa0e67
Please ask if anything is not clear - includes a doc patch as well.
Basically you can do
codenode-admin run -desktop
codenode-admin run -devel
codenode-admin run -settings mysite.settings
or inside an env:
codenode-admin run
2010/1/11 Dorian Raymer <deld...@gmail.com>:
Dorian Raymer
Alex Clemesha
> Hi James,
> I went through the patch and everything was clear.
> Very very nice patch! Besides the simple bug I commented on in the commit,
> and the missing _devel_settings.py file, I think you did a fantastic job
> streamlining the management functions!
> Thanks a lot for taking the time to get this straight, I think it is very
> beneficial to the project!
> I'm particularly fond of how the devel mode is integrated into
> codenode-admin now!
-Alex
--
Alex Clemesha
clemesha.org
James Casbon
http://github.com/jamescasbon/codenode/commit/d1538fb4db4d22b117d35c0526cd3304050777f9
James
2010/1/17 Dorian Raymer <deld...@gmail.com>:
James Casbon
twisted plugins
At the moment we have:
codenode < - must be on pythonpath (and should
be via setup.py)
- codenode < - must be on pythonpath (isn't
without a sys.path manipulation)
- backend
....
- twisted
I'll add another patch later.
2010/1/17 James Casbon <cas...@gmail.com>:
Dorian Raymer
James Casbon
> Hey James,
> I've been using your latest admin-cleanup-2 branch, and I have some more
> questions/feedback.
> - codenode-admin run -desktop is supposed to use ~/.codenode, is that
> correct? Because when I do run -desktop while *not* in a codenode env, it
> creates ~/.codenode if it is not there, but it is not the same as
> codenode-admin init (not everything is copied in, like templates for
> example).
Yes, good spot, I should patch this too.
If we follow this route, then codenode needs to be able to upgrade an
environment by replacing the installed code - another reason I don't
like this route of copying code, but I will do this.
> I like the idea of being able to use -desktop and have the ~/.codenode dir
> be the default env.
> - both codenode-admin frontend and codenode-admin backend create a
> twistd.pid; this makes it so you cannot run them in the same env directory.
> This is fixable by specifing a pid file name (like frontend.pid or
> backend.pid) when starting them (example exists in my devel scripts:
> backend-devel and frontend-devel).
Ok, another patch to do.
> - Had a problem running codenode-admin frontend -devel:
> $ codenode-admin frontend -devel
...
> '/home/dorian/code/github/deldotdr/test_codenode_dec09/testinstallcodenodetemp/lib/python2.5/site-packages/codenode-0.2-py2.5.egg/codenode/frontend/../../devel/env'
The path seems to be wrong - not sure what is causing that. What is
the correct path to the devel directory - does it exist?
> Not sure if i'm just doing it wrong, but it made me realize that for devel
> mode, we don't want to touch the built/installed version of the code; we
> would only ever want to run from a git repository of codenode. So, maybe
> there needs to be an executable copy/link of codenode-admin right in the
> root of the git repository, so that you can explicitly run the non-installed
> version of the code library in a natural, easy way.
> What do you think?
Not sure that's necessary, since devel will pick up the code that is
on the pythonpath (which should be the git one)- of course if you have
two versions on the pythonpath this won't work - do you have two
versions?