On 2/10/06, Max Battcher <[EMAIL PROTECTED]> wrote:
>
> limodou wrote:
> > Using pickle is more harder to modify by hand.
>
> You can always Python shell, load pickle, change, save pickle. Not that
> much more different than load text editor, change, save and quit text
> editor.
django donot support pickle for now. And what I want is exactly that I
don't want to using a text editor to do that and mainly I don't want
to do it manually. I only want a tool can do all of these things, I
only need write a script, and every will execute as my wish. But if I
want to develop such tool, I want some support from django, first
thing is how to parsing configuration files, and saving the
modification, but this things is not very simple. I mean saving a
modification settings.py and urls.py is not easy, because if you want
the output will be as similar as the old one. I hope doing these
things just like what you do in a text editor, but you did it by hand,
and I did it by program. And also these tools you don't need to use,
if you dislike. But someone like me may be happy to with it. So I need
deal with configuration more easily for such tools. And I also
finished a project called djangoinstall(I'v send an email about this,
but it seems no one here care about it.). But the code is very hackly,
and ugly, I want just simple, and maybe someone like me also want to
write his own tool for these things. So if django can provide a easy
way to chang configuration files easily, may be better. If it cann't
support, the code is just ugly and may not be very correctly.
>
> Or you could load the pickle and then check for changes in the text file.
>
> Or you could do whatever else came to mind that didn't require framework
> changes and could make use of the fact that the settings file is just a
> Python script that can have arbitrary code or be introspected by some
> other outside code. Not to sound rude, I don't really care enough to
> come up with a good solution to make you happy. ("Not my problem", "I'm
> not going to need it")
>
> > Ok, you don't know how
> > an automatic tool is useful, so I'll ask you: is django-admin.py
> > useful? is manage.py useful?
>
> My honest opinion (and I apologize for a brief rant) is that these are
> both useful and hindrances. My biggest turn off when I saw Ruby on
> Rails was the *huge* reliance on automatic scripts. No thanks. I think
> that anything that requires such an automatic tool isn't well automated
> in the places that count (the abstractions and framework level).
I don't see there is so many tools in django, but many commands. Why
you say that "I think that anything that requires such an automatic
tool isn't well automated
in the places that count (the abstractions and framework level)." Did
you ever seen paste project, it's a such thing to deploy a web app to
a server. And maybe some project isn't very suit for automatic
process, but it's not mean we don't need a automatice tool at all.
Automatice tool just works like make(may be we can use make to do
that). It can make operation scriptable, and run it. If you don't want
type commands every time, you can make a makefile. That's just like
what you do in a shell script.
>
> That isn't to say that I don't use manage.py, but that I want to make
> sure that I can do everything manage.py can do myself and I know exactly
> what it is doing at every point in its operation. When its my source
> code at stake, when I need to know every corner of the code in case of
> bugs and defects, I'm very wary about any automated tool.
>
> I really like the fact that a similar philosophy has been taken in the
> development of Django's manage.py (versus what it might have been) and
> that magic-removal has furthered removed some of the reliance on the
> tool. (I don't use startapp, for instance.)
So why you donot mention the DRY principle? If everyone like me need
to do the same thing why not provide a handy tool for that. That's why
was manage.py born. What manage.py do just setup PYTHONPATH and
DJANGO_MODULE_SETTINGS I think, setup these things by hand also very
simple, but why manage.py was borned. Just because DRY. So many people
need to do like these. And why don't ask them: write a shell script,
and run it before your work? Just because we won't people redo the
same things. So I think we can do more beyond manage.py had done. And
of cause, if you don't like it, you don't need to run it. So I also
need parsing, reading, saving configuration files just like modify by
hand, but hacking a python script is not very easy for me, so that why
I post this email.
>
> > These are also automatical tools, but
> > they can do only separate task, but not many serials tasks.
>
> Uh, I can certainly do "serial tasks" with manage.py... I have access
> to several available tools such as my Operating System's command scripts
> and I know that I can even write a Python script to run through a small
> list of manage.py actions.
You are exactly do what I want to do, except that you don't want to
change the configuration files programmatically.
>
> > I also
> > want you assume once you need to install many apps to an existed
> > django site, how to do that? Maybe these apps have different
> > directories or different deploy requirements.
> >
> > So how to do that? If we has a deployment specification which
> > describes what things need to do for an automatical deployment tool,
> > and also supply a standard automatic tool and starndard APIs, install
> > apps may be simple. Then writing a corrrect installation script
> > belongs to the author of the app. For an end user, what he need to do
> > is just supply a environment parameters, and run the installation
> > script, so everything is automatically installed correctly. If that is
> > true, I may laugh in sleeping.
>
> Maybe we should look at assumptions: I don't see individual
> applications as "end-user deployable", I expect individual components to
> be pluggable components in an overall Software Design to be installed
> and tested by someone knowledgeable. I don't expect my applications to
> be seen from the same URL scheme, I expect the install-person to decide
> that.
>
What I mean here "end-user" is just a man who is not the author of a
app which the man what to install it. So if I have a app, you want to
install it, you are the "end-user", and you are also a developer too.
Pluggable system is very nice, but how to let django know them, also
need configration. Automatical support doesn't mean you should install
everything into a same place. It'll be a script, just like what I do
in djangoinstall project. You can write a script, tell the tool how to
modify the settings.py and urls.py, and how to copy files, how to make
directories, and how to anything what you want. The tool is also can
be configured. But how to design a automatic tool is another thing,
it's off this topic.
> What I see as the "end-user deployable" solution is a connected Project
> of applications with a designed URL configuration and settings
> configuration, and from what I've seen and done these are deployable
> easily enough.
Automatic tools can be considered to provide a default ways, so you
can modify the configration laterly. Of cause you can modify the
configration of the tool to suit really need. Also that's off this
topic.
>
> This also more closely mirrors any other website deployment style you
> might find.
If you have time, you can see paste project.
>
> So again, the existing work is perfect for my needs, and what you are
> asking for is a huge change with little/no gain for me.
>
Maybe. I don't know much about the core. I just want my work can be
automatically execute, just like I type:
python setup.py install
everything will be automatically installed correctly.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
