Re: Trouble with VirtualEnv on Windows

[Jani Tiainen]

Because the setup procedure used there is faulty.

This is what happens:

When installing Python install package will bind .PY(C) file execution 
to use _always_ main installation. It won't follow any path settings 
which virtualenv relies on.


I'm not sure can you even overcome that restriction easily on cmd. I 
know that powershell can do it (don't know how though) or personally I 
use TCC/LE.


Also psycopg2 is installed on main installation and virtualenv created 
with --no-site-packages should disable it from virtualenv.


This is the battle tested procedure how I do set up my environment:

http://djangonautlostinspace.wordpress.com/2012/04/16/django-and-windows/


15.10.2012 5:45, Joshua Russo kirjoitti:

I suppose I was a little light on the details of how I setup the
environment. I don't often setup a new environment from scratch so I
used this post as the basis:
http://slacy.com/blog/2011/06/django-postgresql-virtualenv-development-setup-for-windows-7/


The versions of each program I used / ended up with were:
Python 2.7.3 (32 bit)
Postgres 9.2 (32 bit)
Setuptools 0.6c11 for Python 2.7
Psycopg2 2.4.5 for Python 2.7 (32 bit)
VirtualEnv 1.8.2
Django 1.4.1



On Sunday, October 14, 2012 6:25:41 PM UTC-4, Joshua Russo wrote:

This is probably a VirturalEnv problem as opposed to a Django
problem but I was wondering if someone here could point me in the
right direction.

I'm trying to setup clean environment for a demonstration of Django
on Tuesday but I get the following when I try to setup the project
within the virtual environment. You can see that if I just run
python from within the virtual environment I do have access to the
libraries, but if I try to use the django-admin.py script, the
libraries aren't found. Any thoughts?

(django-tutorial)
C:\dev\venv\django-tutorial>Scripts\django-admin.py startproject
testsite
Traceback (most recent call last):
   File "C:\dev\venv\django-tutorial\Scripts\django-admin.py", line
2, in 
 from django.core import management
ImportError: No module named django.core

(django-tutorial)
C:\dev\venv\django-tutorial>C:\dev\venv\django-tutorial\Script
s\python.exe
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit
(Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
 >>> from django.core import management
 >>> management

 >>>

--
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/-/YuSLHUyt6xIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.



--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Heroku & Django: Database configuration issues with dj-database-url

[Tuss4]

I'm currently following Heroku's guide to Django on 
Heroku, 
but when it comes to configuring the database in settings.py I'm just at a 
lost. I tried copying and pasting the code provided:

"

import dj_database_url
DATABASES = {'default': dj_database_url.config(default='postgres://localhost')}

"
I end up getting errors when trying to runserver or syncdb. I tried to see if I 
should change the url to something different besides 'postgres://localhost', 
but I still got error. Now before I continue I should mention that 
dj-database-url, django, and psycopg2 installed correctly, but I'm stuck with 
the database settings. Any help would be appreciated.

-- 
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/-/sdRRYa93EMYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Trouble with VirtualEnv on Windows

[Joshua Russo]

I suppose I was a little light on the details of how I setup the 
environment. I don't often setup a new environment from scratch so I used 
this post as the basis: 
http://slacy.com/blog/2011/06/django-postgresql-virtualenv-development-setup-for-windows-7/
 

The versions of each program I used / ended up with were:
   Python 2.7.3 (32 bit)
   Postgres 9.2 (32 bit)
   Setuptools 0.6c11 for Python 2.7 
   Psycopg2 2.4.5 for Python 2.7 (32 bit)
   VirtualEnv 1.8.2
   Django 1.4.1



On Sunday, October 14, 2012 6:25:41 PM UTC-4, Joshua Russo wrote:
>
> This is probably a VirturalEnv problem as opposed to a Django problem but 
> I was wondering if someone here could point me in the right direction.
>
> I'm trying to setup clean environment for a demonstration of Django on 
> Tuesday but I get the following when I try to setup the project within the 
> virtual environment. You can see that if I just run python from within the 
> virtual environment I do have access to the libraries, but if I try to use 
> the django-admin.py script, the libraries aren't found. Any thoughts?
>
> (django-tutorial) C:\dev\venv\django-tutorial>Scripts\django-admin.py 
> startproject testsite
> Traceback (most recent call last):
>   File "C:\dev\venv\django-tutorial\Scripts\django-admin.py", line 2, in 
> 
> from django.core import management
> ImportError: No module named django.core
>
> (django-tutorial) 
> C:\dev\venv\django-tutorial>C:\dev\venv\django-tutorial\Script
> s\python.exe
> Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] 
> on win
> 32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from django.core import management
> >>> management
>  'C:\dev\venv\django-tutorial\lib\site-pack
> ages\django\core\management\__init__.pyc'>
> >>>
>

-- 
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/-/YuSLHUyt6xIJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Cleaning up redis connection after client disconnects from streaming response

[Brent Tubbs]

After a lot of banging on things and reading framework code, I've found 
what I
think is the right answer to this question.

1. According to the WSGI PEP, if your application returns an iterator with a
close() method, it should be called by the WSGI server once the response has
finished. Django supports this too. That's a natural place to do the Redis
connection cleanup that I need.

2. There's a bug in Python's wsgiref implementation, and by extension in
Django's 'runserver', that causes close() to be skipped if the client
disconnects from the server mid-stream. See 
http://bugs.python.org/issue16220.
I've submitted a patch.

3. Even if the server honors close(), it won't be called until a write to 
the
client actually fails. If your iterator is blocked waiting on the pubsub and
not sending anything, close() won't be called. I've worked around this by
sending a no-op message into the pubsub each time a client connects. That 
way
when a browser does a normal reconnect, the now-defunct threads will try to
write to their closed connections, throw an exception, then get cleaned up 
when
the server calls close(). The SSE spec says that any line beginning with a
colon is a comment that should be ignored, so I'm just sending ":\n" as my
no-op message to flush out stale clients.

Sample code for doing this is posted on the Stack Overflow page where I also
posted this question.  See
http://stackoverflow.com/questions/12853067/django-cleaning-up-redis-connection-after-client-disconnects-from-stream

-- 
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/-/ggFglXbVqdYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Most widely used documentation source for Django Projects?

[Robert Steckroth]

Ohh, hey, thanks. It was working this morning and performed flawlessly.
I could not be more happy with the operational tools and overall design.



On Sun, Oct 14, 2012 at 7:19 PM, Russell Keith-Magee
 wrote:
> On Sun, Oct 14, 2012 at 11:54 AM, Robert Steckroth
>  wrote:
>> Hey Gang, is there a standard documentation page for new/existing
>> Django projects?
>> I was going to use https://read-the-docs.readthedocs.org/en but it
>> will not let me create an account (500 whale). It seems to be common
>> in the projects
>> I've used. Any suggestions?
>
> Jump on IRC -- #django-social would be a good bet -- and try and find
> Eric Holscher (ericholscher). He's the maintainer of Read The Docs. At
> the very least, he should be able to confirm that he's aware what the
> problem is.
>
> Yours,
> Russ Magee %-)
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>



-- 
Bust0ut, Surgemcgee: Systems Engineer ---
surgemcgee.com
BudTVNetwork.com
RadioWeedShow.com
"Bringing entertainment to Unix"

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Most widely used documentation source for Django Projects?

[Russell Keith-Magee]

On Sun, Oct 14, 2012 at 11:54 AM, Robert Steckroth
 wrote:
> Hey Gang, is there a standard documentation page for new/existing
> Django projects?
> I was going to use https://read-the-docs.readthedocs.org/en but it
> will not let me create an account (500 whale). It seems to be common
> in the projects
> I've used. Any suggestions?

Jump on IRC -- #django-social would be a good bet -- and try and find
Eric Holscher (ericholscher). He's the maintainer of Read The Docs. At
the very least, he should be able to confirm that he's aware what the
problem is.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: content_type in Client() post doesn't correctly encode

[Russell Keith-Magee]

On Sun, Oct 14, 2012 at 1:48 PM, Christopher Hartfield
 wrote:
> I think I may have a bug in the client test class in the post method.
> Normally you can call:
> url_data = {'something': 'something'}
> response = c.post(ip, url_data, content_type='application/xml')
>
> When I do this I get a 401 response and this data:
> Content-Type: text/html; charset=utf-8
>
> That's it. I don't get any actual data. If I remove the content_type
> argument the problem goes away (but I have the default content type which I
> don't want
>
> I have come across this problem because I am testing an api and it requires
> the content-type to be application/xml.
>
> How do I specify content_type correctly in Django's testing client with post
> data?

The problem isn't the content type definition -- it's what your own
code is doing with the request.

A 401 response indicates that your own render() line isn't being
executed -- you're being bounced for a failed authentication. For some
reason, the client request isn't providing the expected authentication
credentials (either the HTTP_AUTHORIZATION header if you're using HTTP
Basic auth, or the session if you're using a login-based auth, or
possibly something else), and as a result, the client request is being
rejected.

I'm a little confused as to why dropping the content type argument
would alter the outcome, but this must be something to do with your
own code. Django itself doesn't have any 401 (to the extent that there
isn't even a 401 response type defined by default), so the code
raising the 401 isn't anything on Django's side.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Mike Dewhirst]

On 15/10/2012 6:47am, Joshua Russo wrote:

I have project that I have been working and I was contemplating open
sourcing it but I ran into a little hang up. How to handle the database
authentication. The settings file obviously needs to be included but I
don't want to advertise the production database login. How is this
generally handled?


Although best practice seems to be separate local settings files I 
prefer the same settings.py in both development and production. The big 
problem of course is that sensitive information might end up in the 
repository. And I haven't even considered open sourcing.


My solution is a tiny script called getcreds[1] which gets all the 
necessary sensitive info whenever/wherever it is needed. I'm comfortable 
that long in the future nothing sensitive was ever in the repo. That 
includes certificate keys, passwords, userids, email addresses - anything.


I keep a private directory in which all my sensitive creds are kept in 
plain text files with each item on a separate line. I adopt a personal 
convention of userid, password, ip-address, port, etc etc. But it 
doesn't matter because getcreds returns a list and creds[3] or creds[4] 
can mean anything you want[2] in your seetings.


Mike

[1]
# -*- coding: utf-8 -*-
def getcreds(fname, credsdir='/var/creds/'):
""" Return a list of userid and password and perhaps other data.
make sure there are a few empty lines at the end of fname to avoid
keyerrors
"""
creds = []
fname = '%s/%s' % (credsdir, fname)
with open(fname, 'r') as f:
for line in f:
creds.append(line.strip())
return creds

[2]
#excerpt from settings ...
dbhost = getcreds.getcreds('db.host')
DATABASES = {
'default': {
'ENGINE':   'django.db.backends.postgresql_psycopg2',
'NAME': PROJECT,
'USER': dbhost[0],
'PASSWORD': dbhost[1],
'HOST': dbhost[2],
'PORT': dbhost[3],










Also, are there procedures that need to be followed to "properly" open
source a project, or is it really just choosing a licence and dubbing it so?

--
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/-/LJU31pYrcXgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Trouble with VirtualEnv on Windows

[Joshua Russo]

This is probably a VirturalEnv problem as opposed to a Django problem but I 
was wondering if someone here could point me in the right direction.

I'm trying to setup clean environment for a demonstration of Django on 
Tuesday but I get the following when I try to setup the project within the 
virtual environment. You can see that if I just run python from within the 
virtual environment I do have access to the libraries, but if I try to use 
the django-admin.py script, the libraries aren't found. Any thoughts?

(django-tutorial) C:\dev\venv\django-tutorial>Scripts\django-admin.py 
startproject testsite
Traceback (most recent call last):
  File "C:\dev\venv\django-tutorial\Scripts\django-admin.py", line 2, in 

from django.core import management
ImportError: No module named django.core

(django-tutorial) 
C:\dev\venv\django-tutorial>C:\dev\venv\django-tutorial\Script
s\python.exe
Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] 
on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> from django.core import management
>>> management

>>>

-- 
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/-/lVP5ZCW1BpYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Joshua Russo]

Clifford, I have actually done this but the local settings files were 
merely used to override the production values. I think I like this way 
better for handling things like the database and the various path settings, 
though I'm not sure I will completely abandon the override mechanism either.

Thanks for the idea


On Sunday, October 14, 2012 4:56:59 PM UTC-4, CLIFFORD ILKAY wrote:
>
> On 10/14/2012 03:47 PM, Joshua Russo wrote: 
> > I have project that I have been working and I was contemplating open 
> > sourcing it but I ran into a little hang up. How to handle the 
> > database authentication. The settings file obviously needs to be 
> > included but I don't want to advertise the production database login. 
> > How is this generally handled? 
> > 
> > Also, are there procedures that need to be followed to "properly" open 
> > source a project, or is it really just choosing a licence and dubbing 
> > it so? 
>
> Hi Joshua, 
>
> You would have the same issue if you have a staging process where you go 
> from development, testing, and production. We handle that by having a 
> local_config.py that is not checked into the Mercurial repo. At the top 
> of settings.py, we have code that looks like this: 
>
> import local_settings as LOCAL_SETTINGS 
>
> # The following variables are defined in local_settings.py 
> ## 
>
> DEBUG = LOCAL_SETTINGS.DEBUG 
> ADMINS = LOCAL_SETTINGS.ADMINS 
>
> DATABASES = { 
>  'default': { 
> 'ENGINE': LOCAL_SETTINGS.DATABASES['default']['ENGINE'], 
>  'NAME': LOCAL_SETTINGS.DATABASES['default']['NAME'], 
>  'USER': LOCAL_SETTINGS.DATABASES['default']['USER'], 
>  'PASSWORD': LOCAL_SETTINGS.DATABASES['default']['PASSWORD'], 
>  'HOST': LOCAL_SETTINGS.DATABASES['default']['HOST'], 
>  'PORT': LOCAL_SETTINGS.DATABASES['default']['PORT'], 
>  } 
> } 
>
> TIME_ZONE = LOCAL_SETTINGS.TIME_ZONE 
> SECRET_KEY = LOCAL_SETTINGS.SECRET_KEY 
>
> DEFAULT_FROM_EMAIL = LOCAL_SETTINGS.DEFAULT_FROM_EMAIL 
> EMAIL_HOST = LOCAL_SETTINGS.EMAIL_HOST 
> EMAIL_PORT = LOCAL_SETTINGS.EMAIL_PORT 
> EMAIL_HOST_USER = LOCAL_SETTINGS.EMAIL_HOST_USER 
> EMAIL_HOST_PASSWORD = LOCAL_SETTINGS.EMAIL_HOST_PASSWORD 
> EMAIL_USE_TLS = LOCAL_SETTINGS.EMAIL_USE_TLS 
>
> CONTACT_EMAIL = LOCAL_SETTINGS.CONTACT_EMAIL 
>
> INTERNAL_IPS = LOCAL_SETTINGS.INTERNAL_IPS 
>
> # End of variables defined in local_settings.py ## 
>
> local_settings.py can vary from instance of the application to another 
> and those sensitive things like passwords are never kept under revision 
> control. settings.py is consistent regardless of whether it's a 
> development, testing, or production deployment. If you find yourself 
> having to change things in settings.py if you deploy onto another 
> server, chances are it should be factored out into local_settings.py and 
> imported into settings.py as above. 
>
> -- 
> Regards, 
>
> Clifford Ilkay 
> Dinamis 
> 1419-3230 Yonge St. 
> Toronto, ON 
> Canada  M4N 3P6 
>
>  
> +1 416-410-3326 
>
>

-- 
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/-/E1soXgwrEnoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Isuru 2eisuru]

I think best option is project hosting system like github or bitbucket.
Bitbucket allow private hosting too. And version control is attached to it.

On Mon, Oct 15, 2012 at 1:29 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> You could just include the necessary info in the README, or make a wrapper
> script that does it for them - although I tend to stick with READMEs where
> possible as they consume less time.
>
> If the code is coming straight out of production, there's a few tips I'd
> recommended;
>
> * Ensure that you test the code outside of the production environment
> against a test project, and make sure it works as expected.
> * Triple check that you haven't left any private info in the code
> * Provide a (reasonable) amount of documentation
>
> Personally, I tend to opt for this license;
> http://en.wikipedia.org/wiki/WTFPL
>
> There are many places you can put your code (GitHub, my most favourite),
> and others such as BitBucket and Google Code - again it's down to personal
> preference.
>
> Here is an example of a project I open sourced a while back... at the time
> I thought it was done well, but I later realised it needed a serious amount
> of re-writing and documentation - which I still haven't got around to doing;
> https://github.com/foxx/django-cutemodel
>
> Others may be able to offer a bit more advice, but the above is a head
> start at least!
>
> Hope this helps!
>
> Cal
>
> On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo wrote:
>
>> I have project that I have been working and I was contemplating open
>> sourcing it but I ran into a little hang up. How to handle the database
>> authentication. The settings file obviously needs to be included but I
>> don't want to advertise the production database login. How is this
>> generally handled?
>>
>> Also, are there procedures that need to be followed to "properly" open
>> source a project, or is it really just choosing a licence and dubbing it so?
>>
>> --
>> 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/-/LJU31pYrcXgJ.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> 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 django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Cal Leeming [Simplicity Media Ltd]]

Sorry, yes.

Personally whenever I have taken code out of production, I've created a
small example project and then placed the code within it, and created a
scenario where the functionality can be used tested.

This is why open source code sometimes isn't very good quality, it can be a
huge time sink :/

Alternatively, depending on the size of the project, you could just do a
code dump and a blog article about it - but obviously this might not
attract as many people to use it.

Cal

On Sun, Oct 14, 2012 at 9:15 PM, Joshua Russo wrote:

> It sounds like you're saying that the open sourced project should be
> different from the production project. Am I reading that right?
>
>
> On Sunday, October 14, 2012 4:00:03 PM UTC-4, Cal Leeming [Simplicity
> Media Ltd] wrote:
>
>> You could just include the necessary info in the README, or make a
>> wrapper script that does it for them - although I tend to stick with
>> READMEs where possible as they consume less time.
>>
>> If the code is coming straight out of production, there's a few tips I'd
>> recommended;
>>
>> * Ensure that you test the code outside of the production environment
>> against a test project, and make sure it works as expected.
>> * Triple check that you haven't left any private info in the code
>> * Provide a (reasonable) amount of documentation
>>
>> Personally, I tend to opt for this license;
>> http://en.wikipedia.org/wiki/**WTFPL 
>>
>> There are many places you can put your code (GitHub, my most favourite),
>> and others such as BitBucket and Google Code - again it's down to personal
>> preference.
>>
>> Here is an example of a project I open sourced a while back... at the
>> time I thought it was done well, but I later realised it needed a serious
>> amount of re-writing and documentation - which I still haven't got around
>> to doing;
>> https://github.com/foxx/**django-cutemodel
>>
>> Others may be able to offer a bit more advice, but the above is a head
>> start at least!
>>
>> Hope this helps!
>>
>> Cal
>>
>> On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo wrote:
>>
>>> I have project that I have been working and I was contemplating open
>>> sourcing it but I ran into a little hang up. How to handle the database
>>> authentication. The settings file obviously needs to be included but I
>>> don't want to advertise the production database login. How is this
>>> generally handled?
>>>
>>> Also, are there procedures that need to be followed to "properly" open
>>> source a project, or is it really just choosing a licence and dubbing it so?
>>>
>>> --
>>> 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/-/**LJU31pYrcXgJ
>>> .
>>> To post to this group, send email to django...@googlegroups.com.
>>> To unsubscribe from this group, send email to django-users...@**
>>> googlegroups.com.
>>>
>>> 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/-/6nucbxbFRF8J.
>
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[CLIFFORD ILKAY]

On 10/14/2012 03:47 PM, Joshua Russo wrote:
I have project that I have been working and I was contemplating open 
sourcing it but I ran into a little hang up. How to handle the 
database authentication. The settings file obviously needs to be 
included but I don't want to advertise the production database login. 
How is this generally handled?


Also, are there procedures that need to be followed to "properly" open 
source a project, or is it really just choosing a licence and dubbing 
it so?


Hi Joshua,

You would have the same issue if you have a staging process where you go 
from development, testing, and production. We handle that by having a 
local_config.py that is not checked into the Mercurial repo. At the top 
of settings.py, we have code that looks like this:


import local_settings as LOCAL_SETTINGS

# The following variables are defined in local_settings.py 
##

DEBUG = LOCAL_SETTINGS.DEBUG
ADMINS = LOCAL_SETTINGS.ADMINS

DATABASES = {
'default': {
   'ENGINE': LOCAL_SETTINGS.DATABASES['default']['ENGINE'],
'NAME': LOCAL_SETTINGS.DATABASES['default']['NAME'],
'USER': LOCAL_SETTINGS.DATABASES['default']['USER'],
'PASSWORD': LOCAL_SETTINGS.DATABASES['default']['PASSWORD'],
'HOST': LOCAL_SETTINGS.DATABASES['default']['HOST'],
'PORT': LOCAL_SETTINGS.DATABASES['default']['PORT'],
}
}

TIME_ZONE = LOCAL_SETTINGS.TIME_ZONE
SECRET_KEY = LOCAL_SETTINGS.SECRET_KEY

DEFAULT_FROM_EMAIL = LOCAL_SETTINGS.DEFAULT_FROM_EMAIL
EMAIL_HOST = LOCAL_SETTINGS.EMAIL_HOST
EMAIL_PORT = LOCAL_SETTINGS.EMAIL_PORT
EMAIL_HOST_USER = LOCAL_SETTINGS.EMAIL_HOST_USER
EMAIL_HOST_PASSWORD = LOCAL_SETTINGS.EMAIL_HOST_PASSWORD
EMAIL_USE_TLS = LOCAL_SETTINGS.EMAIL_USE_TLS

CONTACT_EMAIL = LOCAL_SETTINGS.CONTACT_EMAIL

INTERNAL_IPS = LOCAL_SETTINGS.INTERNAL_IPS

# End of variables defined in local_settings.py ##

local_settings.py can vary from instance of the application to another 
and those sensitive things like passwords are never kept under revision 
control. settings.py is consistent regardless of whether it's a 
development, testing, or production deployment. If you find yourself 
having to change things in settings.py if you deploy onto another 
server, chances are it should be factored out into local_settings.py and 
imported into settings.py as above.


--
Regards,

Clifford Ilkay
Dinamis
1419-3230 Yonge St.
Toronto, ON
Canada  M4N 3P6


+1 416-410-3326

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Avraham Serour]

I think you should include the config file, but with example parameters and
comments, point out in the readme that there are some basic configuration
to be done

On Sun, Oct 14, 2012 at 9:59 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leem...@simplicitymedialtd.co.uk> wrote:

> You could just include the necessary info in the README, or make a wrapper
> script that does it for them - although I tend to stick with READMEs where
> possible as they consume less time.
>
> If the code is coming straight out of production, there's a few tips I'd
> recommended;
>
> * Ensure that you test the code outside of the production environment
> against a test project, and make sure it works as expected.
> * Triple check that you haven't left any private info in the code
> * Provide a (reasonable) amount of documentation
>
> Personally, I tend to opt for this license;
> http://en.wikipedia.org/wiki/WTFPL
>
> There are many places you can put your code (GitHub, my most favourite),
> and others such as BitBucket and Google Code - again it's down to personal
> preference.
>
> Here is an example of a project I open sourced a while back... at the time
> I thought it was done well, but I later realised it needed a serious amount
> of re-writing and documentation - which I still haven't got around to doing;
> https://github.com/foxx/django-cutemodel
>
> Others may be able to offer a bit more advice, but the above is a head
> start at least!
>
> Hope this helps!
>
> Cal
>
> On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo wrote:
>
>> I have project that I have been working and I was contemplating open
>> sourcing it but I ran into a little hang up. How to handle the database
>> authentication. The settings file obviously needs to be included but I
>> don't want to advertise the production database login. How is this
>> generally handled?
>>
>> Also, are there procedures that need to be followed to "properly" open
>> source a project, or is it really just choosing a licence and dubbing it so?
>>
>> --
>> 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/-/LJU31pYrcXgJ.
>> To post to this group, send email to django-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> django-users+unsubscr...@googlegroups.com.
>> 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 django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Joshua Russo]

It sounds like you're saying that the open sourced project should be 
different from the production project. Am I reading that right?


On Sunday, October 14, 2012 4:00:03 PM UTC-4, Cal Leeming [Simplicity Media 
Ltd] wrote:
>
> You could just include the necessary info in the README, or make a wrapper 
> script that does it for them - although I tend to stick with READMEs where 
> possible as they consume less time.
>
> If the code is coming straight out of production, there's a few tips I'd 
> recommended;
>
> * Ensure that you test the code outside of the production environment 
> against a test project, and make sure it works as expected.
> * Triple check that you haven't left any private info in the code
> * Provide a (reasonable) amount of documentation
>
> Personally, I tend to opt for this license;
> http://en.wikipedia.org/wiki/WTFPL
>
> There are many places you can put your code (GitHub, my most favourite), 
> and others such as BitBucket and Google Code - again it's down to personal 
> preference.
>
> Here is an example of a project I open sourced a while back... at the time 
> I thought it was done well, but I later realised it needed a serious amount 
> of re-writing and documentation - which I still haven't got around to doing;
> https://github.com/foxx/django-cutemodel
>
> Others may be able to offer a bit more advice, but the above is a head 
> start at least!
>
> Hope this helps!
>
> Cal
>
> On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo 
>  > wrote:
>
>> I have project that I have been working and I was contemplating open 
>> sourcing it but I ran into a little hang up. How to handle the database 
>> authentication. The settings file obviously needs to be included but I 
>> don't want to advertise the production database login. How is this 
>> generally handled?
>>
>> Also, are there procedures that need to be followed to "properly" open 
>> source a project, or is it really just choosing a licence and dubbing it so?
>>
>> -- 
>> 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/-/LJU31pYrcXgJ.
>> To post to this group, send email to django...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to 
>> django-users...@googlegroups.com .
>> 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/-/6nucbxbFRF8J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Best practices for open sourcing a Django project?

[Cal Leeming [Simplicity Media Ltd]]

You could just include the necessary info in the README, or make a wrapper
script that does it for them - although I tend to stick with READMEs where
possible as they consume less time.

If the code is coming straight out of production, there's a few tips I'd
recommended;

* Ensure that you test the code outside of the production environment
against a test project, and make sure it works as expected.
* Triple check that you haven't left any private info in the code
* Provide a (reasonable) amount of documentation

Personally, I tend to opt for this license;
http://en.wikipedia.org/wiki/WTFPL

There are many places you can put your code (GitHub, my most favourite),
and others such as BitBucket and Google Code - again it's down to personal
preference.

Here is an example of a project I open sourced a while back... at the time
I thought it was done well, but I later realised it needed a serious amount
of re-writing and documentation - which I still haven't got around to doing;
https://github.com/foxx/django-cutemodel

Others may be able to offer a bit more advice, but the above is a head
start at least!

Hope this helps!

Cal

On Sun, Oct 14, 2012 at 8:47 PM, Joshua Russo wrote:

> I have project that I have been working and I was contemplating open
> sourcing it but I ran into a little hang up. How to handle the database
> authentication. The settings file obviously needs to be included but I
> don't want to advertise the production database login. How is this
> generally handled?
>
> Also, are there procedures that need to be followed to "properly" open
> source a project, or is it really just choosing a licence and dubbing it so?
>
> --
> 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/-/LJU31pYrcXgJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> 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 django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Best practices for open sourcing a Django project?

[Joshua Russo]

I have project that I have been working and I was contemplating open 
sourcing it but I ran into a little hang up. How to handle the database 
authentication. The settings file obviously needs to be included but I 
don't want to advertise the production database login. How is this 
generally handled?

Also, are there procedures that need to be followed to "properly" open 
source a project, or is it really just choosing a licence and dubbing it so?

-- 
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/-/LJU31pYrcXgJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Regarding the sub domains

[creecode]

These comments are for the OP, I'm just using Christopher's message to key 
off of...

On Saturday, October 13, 2012 10:59:56 PM UTC-7, Christopher Hartfield 
wrote:

You would have to yes first configure your name servers and allow your 
> website example.com to resolve each of those subdomains.  So hopefully 
> your number of users won't be too high :(  If your allowed you might find 
> it easier to do example.com/moris/, but I would assume you can't do that.


For your name server you'll want to use a 
wildcard
.

Django can handle subdomains with certain plugins like: 
> http://django-subdomains.readthedocs.org/en/latest/index.html
>

You don't have to use a Django app to handle subdomains, all the routing 
can be handled with your webserver (like Apache, etc.)  It just depends on 
where you want to do your configuring. 
 

> Setting up multiple databases isn't too hard and you can use RAW SQL to 
> help you with it. 
>
 

> Django supports multiple databases (but I'm not sure you can use Django to 
> create a new db on the fly)
>

You can get Django to create a new database on the fly with the use of a 
custom management command.  Essentially you'll be using RAW SQL in the 
management command to do the database creation bit.  Keep in mind that you 
need to have a Django environment setup to use the custom management 
command.  That involves some overhead which only you'll be able to 
determine if it is appropriate for your situation.

You may want to read this thread on one way to do mass 
hostingif 
you're going to use mod_wsgi.

Toodle-loo
creecode

-- 
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/-/1_XG0SfjoA0J.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Sub-arguments to arguments in management commands

[Joel Goldstick]

On Sun, Oct 14, 2012 at 12:12 PM, Robert Steckroth
 wrote:
> Hey Gang, I have to Command class below which utilizes args from the
> command line.
> I would like to have sub-arguments to some of these,
> e.g. python manage.py template3d -c --file some_template.html another.html
>

I've not tried this package, but I saw a video and it looked interesting

http://pypi.python.org/pypi/docopt/0.1

It lets you define your parameters in the docstring.

>
> I appreciate your time, Robert.
>
>
> --
> Bust0ut, Surgemcgee: Systems Engineer ---
> surgemcgee.com
> BudTVNetwork.com
> RadioWeedShow.com
> "Bringing entertainment to Unix"
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>



-- 
Joel Goldstick

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Sub-arguments to arguments in management commands

[Robert Steckroth]

Hey Gang, I have to Command class below which utilizes args from the
command line.
I would like to have sub-arguments to some of these,
e.g. python manage.py template3d -c --file some_template.html another.html

This would execute the [-c] parameter and also pass those html names
to a [--file] option.

It is proving very difficult to find answers on the net.


class Command(BaseCommand):

  help='Coverts django templates for use with the Template3D system.
Obfuscates and minimizes Javascript, CSS, and HTML'
  option_list = BaseCommand.option_list + (
  make_option('-o', '--optimize', action='store_true', dest='optimize',
default=False, help='Convert all templates in the into the
templates3d format without any code minification.'),
  make_option('-c', '--compile', action='store_true', dest='closure',
default=False, help='Compile all templates. (Includes
minimizing: Javascript, CSS, and HTML).'),
  make_option('-u', '--unoptimize', action='store_true', dest='unoptimize',
default=False, help='Reverts all templates to the
non-optimized original version.'),
  make_option('-U', '--uncompile', action='store_true', dest='uncompile',
default=False, help='Reverts all templates to the
non-minimzed original version.'),
  make_option('-d', '--create-directories', action='store_true', dest='create',
default=False, help='Automatically creates the directory
structure contained in the STANDARD_TEMPLATE_DIRS to the
TEMPLATE_DIRS.'),
)

  def handle(self, *args, **options):
template_3d = template3d()

if options['create']:
  template_3d.create_directories()



I appreciate your time, Robert.


-- 
Bust0ut, Surgemcgee: Systems Engineer ---
surgemcgee.com
BudTVNetwork.com
RadioWeedShow.com
"Bringing entertainment to Unix"

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Global timeout for views

[Karen Tracey]

On Sat, Oct 13, 2012 at 10:43 AM, Sudhir Kumar  wrote:

> Is there a way to setup a global timeout for all views?
>
> Some of the requests are taking too long. I would like to log those and
> send an error response back. If possible, I would NOT  like to delegate
> timeout to upstream load balancer. What is the best way to achieve this in
> Django.
>
>
There is nothing built in to Django for this. You may want to take a look
at these external projects:

https://bitbucket.org/evzijst/dogslow
https://bitbucket.org/evzijst/interruptingcow

I heard about them at the talk "Healthy Webapps Through Continuous
Introspection" by Erik van Zijst at DjangoCon EU this summer. See:

http://lanyrd.com/2012/djangocon-europe/srptg/

for slides/video. I have not had a chance to try these tools out yet
myself, but they are on my list for next time I find myself needing to
figure out why some views are slow.

Karen
-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: User can't edit model even after permissions are issued

[Karen Tracey]

On Fri, Oct 12, 2012 at 4:52 PM, Shawn H  wrote:

> I'm new to Django, and I'm using the admin site to manage my users.  I
> have one app installed, and it has one model.  I created a new user, issued
> that user add, change, and delete privileges (as app | model | privilege),
> but when I log on as that user, I get the "you don't have permission to
> edit anything" error.  The user is active and is staff, but no joy.  What
> might I be missing?


Are the app's models registered in admin?

-- 
http://tracey.org/kmt/

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

foreign key: need to instantiate a form with the initialized foreign key value

[Malik Aqib]

class HmsPatient(models.Model):
id = models.IntegerField(primary_key=True)
regdatetime = models.DateTimeField(default=datetime.datetime.now())
name = models.CharField(max_length=576)
dob = models.DateField(default=datetime.datetime.now())
email = models.CharField(max_length=1152)
mobile = models.CharField(max_length=144)
gender = 
models.CharField(max_length=18,default="Male",choices=gender_choice)
religion = 
models.CharField(max_length=27,default="Muslim",choices=religion_choice)
marital_status = 
models.CharField(max_length=288,default="Unmarried",choices=marital_choice)
guardian_name = models.CharField(max_length=576)
guardian_relation = 
models.CharField(max_length=288,default="Father",choices=relation_choice)
address = models.CharField(max_length=2304)
city = models.CharField(max_length=576,default="Srinagar")
state = models.CharField(max_length=576,default="J")
country = 
models.CharField(max_length=576,default="India",choices=country_choice)
class Meta:
db_table = u'hms_patient'


class HmsDiagnosis(models.Model):
id = models.IntegerField(primary_key=True)
regid = models.ForeignKey(HmsPatient, db_column='regid')
datetime = models.DateTimeField(default=datetime.datetime.now(), 
auto_now=True)
provisional_diagnosis = models.CharField(max_length=500, null=True, 
blank=True)
remark = models.CharField(max_length=500, null=True, blank=True)
biochemistry = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
stool = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
blood = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
colonoscopy = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
gastroscopy = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
urine = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
xray = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
sonography = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
ecg = 
models.CharField(max_length=9,choices=yes_no_enum_choice,default="Yes")
others = models.TextField()
reconsultation_date = models.DateField(null=True, blank=True)
class Meta:
db_table = u'hms_diagnosis'



-- 
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/-/diz8r-28fzkJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Regarding the sub domains

[Christopher Hartfield]

You would have to yes first configure your name servers and allow your 
website example.com to resolve each of those subdomains.  So hopefully your 
number of users won't be too high :(  If your allowed you might find it 
easier to do example.com/moris/, but I would assume you can't do that.

Setting up multiple databases isn't too hard and you can use RAW SQL to 
help you with it. 

Django can handle subdomains with certain plugins 
like: http://django-subdomains.readthedocs.org/en/latest/index.html
But you still have to configure the name servers.  

So your goal would be to sign up a new user and then make a database for 
the user, add the tables and insert into the tables

Django supports multiple databases (but I'm not sure you can use Django to 
create a new db on the fly):
https://docs.djangoproject.com/en/dev/topics/db/multi-db/

Hopefully this gets you started

On Saturday, October 13, 2012 4:25:36 AM UTC-7, Monty0nWeb wrote:
>
> Hi, 
>
> We have multiple users and each user needs to have a subdomain along with 
> a separate database for each one of them, 
>
> Like *moris.example.com*  .  to have a database by name moris or 
> something like that,
> and so on for different customers.
>
> Having multiple databases is necessary because of policy they have. 
>
> What is the best approach to do this, i just saw many discussions on 
> stackoverflow, where they said having such a set up is not advisable. But 
> here i cant really go with it. 
>
> What is the best way to go about this? Please advice. 
>
>
>
> Thanks 
>
>
>
> -- 
>
>

-- 
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/-/GsNLRKmZjnoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.