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 <[email protected] <javascript:>> > http://blog.asadjb.com > > On Wed, Aug 24, 2016 at 9:24 PM, Andreas Kuhne <[email protected] > <javascript:>> wrote: > >> >> 2016-08-24 17:54 GMT+02:00 Michael Macdonald <[email protected] >> <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 [email protected] <javascript:>. >>> To post to this group, send email to [email protected] >>> <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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <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 [email protected]. To post to this group, send email to [email protected]. 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.
