Good points. I tend to merge the roles of developer and QA in my mind when thinking of Django, since it is not my day-job and I'm working alone. That said, you are correct, when doing something more than quick-hit problem resolution, I'm guessing I'd wind up going back to runserver. I do still see a need to configure a production-like execution path on one's local development machine. Even with a QA department (or separate QA environment at any rate), I would think it would save some iterations being able to validate runserver vs. web-server execution prior to handing off.
On Wednesday, August 24, 2016 at 11:32:54 AM UTC-7, Asad Jibran Ahmed wrote: > > One thing I'd add to this is that I could never work without runserver > because I tend to use ipdb a *lot* while debugging any problems. For me > the best way to debug is to put import ipdb; ipdb.set_trace() in my code > and just start debugging from the command line. Having uwsgi or any other > kind of server running my Django code takes away that ability, and I'd be > in hell trying to figure out errors without that. > > Just my 2 cents. > > Asad Jibran Ahmed <surf...@gmail.com <javascript:>> > http://blog.asadjb.com > > On Wed, Aug 24, 2016 at 9:24 PM, Andreas Kuhne <andrea...@suitopia.com > <javascript:>> wrote: > >> >> 2016-08-24 17:54 GMT+02:00 Michael Macdonald <mmacdonald...@gmail.com >> <javascript:>>: >> >>> Interestingly enough, just this morning, after a couple times being >>> bitten with differences in behavior between use of runserver in development >>> vs. wsgi in production, I've decided to do all development on my local >>> machine under lighttpd. In the process of (mis?)configuring it now. >>> >>> I'm pretty thoroughly convinced that using runserver isn't such a good >>> idea, nor is it particularly useful. Development I've done under Eclipse >>> and MS VisualStudio in the past did initial local unit testing on a local >>> server; there is ample precedent for this approach. And, it is best >>> practice to make the development environment as close to the same as the >>> production environment as possible. >>> >>> In retrospect, I'm surprised I ever used runserver... >>> >>> On Wednesday, August 24, 2016 at 12:25:52 AM UTC-7, Lekan Wahab wrote: >>>> >>>> Good morning, >>>> I was recently given a django project to manage at work. >>>> However, i noticed the project has neither a django-admin.py or a >>>> manage.py file. >>>> Is that normal? >>>> If it is, how do i run the project on my local machine for testing >>>> purposes? >>>> >>>> The file structure is something like this: >>>> Project Name >>>> app1 >>>> app2 >>>> app3 >>>> app4 >>>> app5 >>>> models.py >>>> forms.py >>>> __init__.py >>>> urls.py >>>> views.py >>>> admin.py >>>> >>>> >>>> Each app contains the following: >>>> models.py >>>> forms.py >>>> __init__.py >>>> urls.py >>>> views.py >>>> admin.py >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-users...@googlegroups.com <javascript:>. >>> To post to this group, send email to django...@googlegroups.com >>> <javascript:>. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/f72d16e6-eb11-4a48-a89e-b51a6006d24e%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-users/f72d16e6-eb11-4a48-a89e-b51a6006d24e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> What you get with runserver is automatic reloading - you don't get that >> running the application behind a webserver. If you run a django app behind >> anything else except runserver, you will need to restart the server every >> time you change your code. You will still need to try the application in a >> production environment, but that is why you have a staging environment (or >> test). You also need to have a place where QA can test everything (or the >> product owner) - this environment should be as close to the production >> environment as possible - so that discrepancies can be found there. >> >> Regards, >> >> Andréas >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-users...@googlegroups.com <javascript:>. >> To post to this group, send email to django...@googlegroups.com >> <javascript:>. >> Visit this group at https://groups.google.com/group/django-users. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-users/CALXYUb%3DsXv2xtVW2Bet6jwLQRaQgV1DB9EbiUAHdF43tKPKRZA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/django-users/CALXYUb%3DsXv2xtVW2Bet6jwLQRaQgV1DB9EbiUAHdF43tKPKRZA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/a9cc2b83-b979-4df1-974f-0a17dcf1b6f5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
