Re: django-admin.py startproject will NOT work.
At 2012-01-01 14:23:50 -0800, Chris Kavanagh wrote: > On Jan 1, 4:44 am, Bart Nagel wrote: > > At 2012-01-01 01:12:27 -0800, Chris Kavanagh wrote: > > > > > On Dec 31 2011, 7:13 pm, Bart Nagel wrote: > > > > When I run that I get > > > > 3 arguments: ['args.py', 'startproject', 'mysite'] > > > > > > Paste your own output. > > > > > I get the same as you: > > > > > C:\Python27\Scripts>python args.py startproject mysite > > > 3 arguements: ['args.py', 'startproject', 'mysite'] > > > > What's with the spelling error? > > LOL, well apparently I don't know how to spell 'argument'. > > However, I still got the same output as you (except for correct > spelling). > > What exactly were we (you) looking for in this test?? I explained that in a previous post. Afraid I can't help you any further, though I'm glad you eventually got it working. --bart -- 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: django-admin.py startproject will NOT work.
At 2012-01-01 01:12:27 -0800, Chris Kavanagh wrote: > On Dec 31 2011, 7:13 pm, Bart Nagel wrote: > > When I run that I get > > 3 arguments: ['args.py', 'startproject', 'mysite'] > > > > Paste your own output. > > I get the same as you: > > C:\Python27\Scripts>python args.py startproject mysite > 3 arguements: ['args.py', 'startproject', 'mysite'] What's with the spelling error? -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 18:56:14 -0800, Chris Kavanagh wrote: > Ok I've had a breakthrough (I guess,lol). I started a command prompt > from my Python Scripts folder (C:\Python27\Scripts\), typed in "Python > django-admin.py startproject mysite", and it worked!! I now have the > "mysite" folder with appropriate subfolders (__init__.py, > manage.py,settings.py,urls.py). It still doesn't make sense that it wasn't working before. Did you try the modified args.py script I sent you? > Is this working correctly?? Should I have to create Projects in the > Python Scripts Folder?? Should it work from another (any misc dir) > dir?? If Python itself and the django-admin.py script were being found properly (and they were when you were getting the help message), yes, you should be able to do that from any directory. > And, can I leave it in the Scripts Folder or should I move it?? If I > do move it, will that cause other problems?? You should probably move it. It should work anywhere, again, as long as it can find Python properly. --bart -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 18:47:13 -0800, Chris Kavanagh wrote: > Forgive my ignorance, but if that's the way it's supposed to work > (script must be in current dir) then how would Python know to run > django-admin.py if I'm NOT in the same directory it is > (Python27\Scripts\)??? In other words, the tutorial says to create a > mysite dir somewhere, NOT in the Python27\Scripts dir. So how would it > work then if Python27\Scripts\ isn't my current working dir (ie: > mysite isn't in the Scripts dir)?? Three options: Either you run python C:\path\to\django-admin.py startproject mysite from whatever directory you want, to run an arbitrary Python script anywhere on your machine. Or, with other scripts, from the directory where the Python script is, you can generally do python some-script.py C:\path\to\some\target depending how the script itself is set up -- the django-admin.py doesn't let you do this, it wants only to create a project in the current directory. Or (what you're encouraged to do in this case) the django-admin.py script is set up somewhere in your lookup PATH. The lookup PATH is the list of directories in which commands live, and so when asked to run a particular command the shell looks in those directories and if it finds the command you wanted runs it, no matter where you are. To get the django-admin.py script in the PATH so you can run it from anywhere without a full path either you install the script to a directory which is already in your PATH (I think on Windows C:\windows\system32 is one such directory) or the Django directory containing the script is added to your PATH. There might have been instructions to do that when you installed Django, or perhaps it was done as part of an installation script. The fact that this path exists is the reason you can run commands like "python" itself from anywhere, if it's set up properly. -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 16:00:44 -0800, Chris Kavanagh wrote: > On Dec 31, 6:48 pm, Bart Nagel wrote: > > Does this little script tell you correctly the number of arguments you > > pass to it? > > Yes, it tells me the number of args. Okay, in that case the arguments should also be getting to the django-admin script. To give you the help message it must not be able to read the "startproject" argument, since the name of the project shouldn't matter to it. Perhaps something bad is happening to it, possibly due to the registry stuff you folks were talking about earlier, or some other Windows sorcery. Change args.py a little to this: import sys print "%d arguments: %s" % (len(sys.argv), sys.argv) And now run it with the arguments you were trying to give to django-admin: python args.py startproject mysite When I run that I get 3 arguments: ['args.py', 'startproject', 'mysite'] Paste your own output. --bart -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 15:43:36 -0800, Chris Kavanagh wrote: > Ok, I CAN start the Python Interpreter from the command line by just > typing "python" then "enter". > > I saved the file "args.py" in the Python Scripts folder. When I try to > run it from command prompt, I get the message "python: can't open > file 'args.py': [Errno 2] No such file or directory". > > The only way I CAN get it to open, is to change (cd into) into the > python scripts folder (where I saved args.py) then run it (type > "python args.py" in command prompt). So, obviously something is wrong. No, that's not wrong, that's how it should be. The python interpreter is in your path, but you're telling the interpreter which file to run. If you tell it to run a file args.py and there is no such file in the current directory, it's correct to give you an error message. Does this little script tell you correctly the number of arguments you pass to it? --bart -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 15:01:39 -0800, Chris Kavanagh wrote:
> On Dec 31, 11:58 am, Bart Nagel wrote:
> > What about other Python programs? Do they have the same problem?
> >
> > Put this next paragraph in a file and run it with different numbers of
> > arguments and see what happens.
> >
> > import sys
> > print "%d arguments" % len(sys.argv)
> >
> > Save it as args.py
> >
> > Run
> > python args.py
> > python args.py arg1
> > python args.py arg1 arg2
>
> As far as other programs, I'm not sure. I'm not a programmer (just
> learned Python over the last few months) so I haven't tried any other
> programs yet.
>
> Ok, so save the paragraph in a file, then run the commands from the
> command line EXACTLY as you have them? In other words, from command
> line, type in Python args.py, then python args.py arg1, and python
> args.py arg 2??
>
> Forgive my ignorance, working from the command line with this stuff is
> new to me. And I've never understood exactly what command line args
> are. . .But I'm learning.
The command line is the dream, you'll come to love it. Well, maybe not
the Windows one.
I guess first up just run
python
and see if you get the interactive Python shell. Or maybe you need
python.exe
since you're on Windows? Anyway, if you get the shell, the python
executable is in your path and works to at least some extent. If you
don't get the shell, and you get "command not found" or something (I
don't have a Windows box so I don't know exactly what it would look
like) you may need to use the full path to the executable, as people
before have suggested.
So those two lines ("import..." and "print...") make a very simple
Python script which just outputs the number of arguments it thinks it
was given.
Invoke the script with Python just as you're meant to do for the
Django script. On linux I just run
python args.py
and it tells me "1 arguments". If I run
python args.py something
it tells me "2 arguments" and so on.
What behaviour do you get?
The point of this is that if this python script can see the arguments
then I can see absolutely no reason why your django-admin.py script
would not see them, and I would be stumped.
--bart
--
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: django-admin.py startproject will NOT work.
At 2011-12-31 19:47:35 +0300, Timothy Makobu wrote: > File associations are fine i reckon, because django-admin is giving you the > help message because for some reason it thinks you're *giving it improper > input*. What about other Python programs? Do they have the same problem? Put this next paragraph in a file and run it with different numbers of arguments and see what happens. import sys print "%d arguments" % len(sys.argv) Save it as args.py Run python args.py python args.py arg1 python args.py arg1 arg2 -- 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: django-admin.py startproject will NOT work.
At 2011-12-31 08:40:26 -0800, Chris Kavanagh wrote: > While looking for a solution, I found someone with a similar problem. > he thought there was a problem with the way Python Files are > associated. So I did what was suggested on the command line, using > "assoc.py" and ftype Python.File. What I got back is listed below. I > don't think this is right according to what the message said. > According to him, it should've returned ".py=Python.File" and > "Python.File="C:\Python25\python.exe" "%1" %*". . .Obviously mine was > different. Any suggestions??? > > > > > C:\>assoc .py > .py=py_auto_file > > C:\>ftype python.file > File type 'python.file' not found or no open command associated with > it. Try ftype py_auto_file -- 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: Constraints on a one-to-many relationship and related problems
At 2011-12-28 06:59:31 -0800, Jay De Lanoy wrote: > I'd go for a separate table instead, with something like > > class BillingInfo(models.Model): > customer = models.OneToOneField(Customer) > billing_address = models.OneToOneField(Address) > > and then just have logic in the views and templates to account for > existence/nonexistence of a given customer's billing address. Would this approach mean implementing my own forms to populate customers and addresses and not using the built-in Django admin forms at all? They were a major draw for me to Django. Thanks. --bart -- 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: Constraints on a one-to-many relationship and related problems
At 2011-12-28 06:21:38 -0800, Dan Gentry wrote: > Just looking at the models, I'd like to make a couple of suggestions. > > Instead of using a Foreign Key relationship in Customer to indicate > the billing address, I would include a flag called 'billing_address' > in the Address table that would be set to True for the customer > selected address. > > An override of save() in the Address model is then used to enforce the > 'only one billing address' rule. This certainly simplifies things, but there are still a couple of problems. Firstly, the user gets no warning if he checks multiple "is billing address" boxes on the inline forms and it doesn't seem to be totally predictable which of the addresses' save methods will be called, and then which will be called last, and therefore which will end up being marked as the billing address. Any suggestions? Or is there a way to make them show up as radio buttons? Next, there's nothing to stop no addresses being given, or no addresses being marked as the billing address. I guess I could put the monkey patch back on so I can force the first address to be billing if none is. Is that the best solution to this problem? But even then the problem of how to stop a customer being created if no addresses are given remains. Thanks. --bart -- 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.
Constraints on a one-to-many relationship and related problems
e billing address). But at this point it's too late to throw pretty exceptions if something goes wrong, which is a shame. There's another problem there too. Once the billing address is set to one of the addresses and then the customer's addresses are later edited again I get horrific errors saying that the billing address is set to an unacceptable option. I think what's happening is that the addresses are being deleted and recreated, and so the reference in the billing address field now points to a non-existent primary key in the addresses table. Since the above doesn't let me warn the user if they haven't entered any addresses, I needed another approach to let me do that. What I came up with was setting up a custom ModelForm for the Customer object's admin interface, and checking in the clean() method there. The best I could think to do was to print out dir() of various things to find likely looking methods and to see what data I had. The only reference to the addresses being entered I could find was in the self.data dict there. And it's messy, but I got a solution half-working by looking at self.data["address_set-TOTAL_FORMS"] and checking the number. But that doesn't cover all possibilities -- it might not exist (easy to deal with) and, slightly harder, some of the forms sent might have the "delete" box checked. So I had to count up to the number of forms and look for "address_set-%n-DELETE" keys. It's a mess and there's still a case it doesn't catch -- when a form is sent with the default (untouched) values and so doesn't actually end up creating an address. I'd see it as being an address and let it through, but then the billing address wouldn't have anything to point to. I didn't try to write code to handle that case because it's just getting way too messy. So this solution is not working for me. In fact, looking back, none of my solutions for any of the problems are adequate. I'm stuck. Please help! Any suggestions are appreciated. Hopefully there are just some really easy things I've missed in the documents which will solve everything, but if the solution is a bit more in depth, so be it. --bart nagel -- 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.
