On Sat, Oct 6, 2012 at 12:04 PM, Xun Yang <[email protected]> wrote:
> Hi ke1g! Thanks a lot for the explanation! I'm currently using both the
> second and third approach for the problem, a utility app for a few things
> and embedding "registration" app in my project (Seeing it hasn't updated for
> years, I suppose it's safe to have it here and modify as I want). At certain
> point I may need to break utility app into new apps as the project goes. I'm
> also getting curious about the "requirements.txt" you talked about, seems
> like I need some good knowledge about version control.
Python has package management stuff. The older "easy_install" is out
of favor, and people seem to prefer "pip", which is based on the
"distribute" app packaging system. Both can be found on pypi:
http://pypi.python.org/pip
http://pypi.python.org/distribute
(The former requires the latter to be installed first, if you're not
already using them.)
You can have a "requirements" file, listing a number of packages, and
specifying the desired version number (or allowable range) for each
package. If you call it "requirements.txt" (the name doesn't matter,
but this seems to be a common choice), then you can say:
pip install -r requirements.txt
And pip will see to it that you have those versions of those packages
installed (plus any requirements that they specify). There is syntax
for a requirements file to include others, which I've seen used when
the set of packages needed for, say, Windows is slightly different
than those needed on Linux. Have a windows.txt and a linux.txt, each
of which include a base.txt, and specify the correct one of the first
two depending on where you're deploying. I've also seen this used to
add debugging packages on a development server that one doesn't want
in production. Sort of poor man's configuration management.
(Another possibility is zc.buildout, but that always makes my head
spin. I'm just not in the right mindset for it.)
We put that file, along with our settings, urls, and custom apps
(manage.py and wsgi.py too) under version control. Then when I get
something working on my desktop, I check it in to my local Mercurial
repository, push that to our remote development server (for access
from outside our local network) for further testing. Ssh'ed into the
development server, I tell Mercurial to update to tip, and if I've
added any new packages from the outside world, run pip install -r
requirements.txt, restart apache, and solicit my co-developers to do
further testing. If all goes well, the production server can pull the
new changes. If something is later discovered to be broken, on the
production server I can revert to the last revision that worked, so
that it works properly while I figure out what's wrong back on the
development server.
>
> I hope the Django community has a plan of moving the support group out of
> Google Groups, which feels like a last century product and is hard to both
> keep track and read...
>
>
> On Friday, October 5, 2012 10:25:27 PM UTC+2, ke1g wrote:
>>
>> If your changes are limited to templates, there is an easy standard
>> approach:
>>
>> Set TEMPLATE_DIRS to something reasonable.
>> Include the file system template loader in TEMPLATE_LOADERS
>> *before* the app loader. (This is probably already true.)
>>
>> Copy the templates you need to change to the same sub path of your
>> templates directory as they were to the app's templates directory, and
>> edit your copy. E.g.; if the foo app calls out a template as
>> "foo/bar.html", and the original is in
>> ".../site-packages/foo/templates/foo/bar.html", and you put your
>> version in ".../templates/foo/bar.html", your version will be found
>> first, and thus will be the one used.
>>
>> If you need to fiddle a view, you need to recreate the view (or, if
>> applicable, create a function that calls the view and massages the
>> arguments and/or the results) in a module of your own that is
>> available from sys.path, e.g.; ".../my_utils/extra_views.py", and fix
>> urls.py to call it instead. You can do this even if you are
>> "include()"ing the apps urls module from your urls, since you can put
>> an expression that matches a specific on or the app's sub paths before
>> the include, and the other sub paths will still be handled by the
>> app's urls.
>>
>> Fancier changes usually lead to cloning the app into your project
>> directory and putting it under your revision control system, rather
>> than in requirements.txt (or equivalent). (Your project directory
>> needs to be, and typically will be, earlier on sys.path than
>> site-packages or (yuck) dist-packages.)
>>
>> Installing upgrades to other packages CAN (but usually doesn't) break
>> any of these approaches, requiring you to track down the interaction
>> and edit your copy.
>>
>> On Thu, Oct 4, 2012 at 5:53 AM, Xun Yang <[email protected]> wrote:
>> > Quite often I have to make small changes to the original code when I'm
>> > using
>> > default/3rd part apps. Take an example of setting constrains for
>> > password,
>> > the default SetPasswordForm in django.contrib.auth.forms and
>> > RegistrationForm in django-registration don't have any. So I have to
>> > subclass them and add in the checks. So is there a best practice of
>> > where to
>> > place these subclasses? As in one project I may need to define many
>> > subclasses from various default/3rd part apps, should I create a utility
>> > app
>> > and put all of them there? (From the past experience I'm a bit concerned
>> > about this, as it could be a source of pain when I moved stuff from test
>> > to
>> > WSGI/apache)
>> >
>> > Thanks for the help!
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Django users" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/django-users/-/IOBUs2rA9UoJ.
>> > To post to this group, send email to [email protected].
>> > To unsubscribe from this group, send email to
>> > [email protected].
>> > For more options, visit this group at
>> > http://groups.google.com/group/django-users?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/mR0mzEPyGeMJ.
>
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
