Hi Nate, I guess I'm personally just burnt by the PaaS model in general - it's a very limited-scope way of modelling applications, I've never had it work for anything serious, and in particular every attempt I've seen at something that targets multiple PaaS hosts ultimately ends up only having the core feature set of the lowest common denominator. A lot of small projects are transitioning from PaaS to more "traditional" hosting, and I'm not sure if this would help there.
Though it's too late for this GSOC, I'd rather like to see work on the parts of Django that actually do affect deploy-ability for everyone, like database configuration through a standard set of environment variables and sorting out settings and how Django expects to find production vs. development settings. I know that's a terrible argument, akin to the "why are all the physicists colliding particles when they should be curing cancer?!", but I do generally feel a little that tailoring to just a certain specific set of PaaS providers is kind of papering over the problem. Anyway, if the proposal is good and you're willing to mentor, I don't see why we shouldn't accept it - you have commit access to the target project, after all, and it'll set a good precedent - and it's worth seeing what issues come up, because just knowing what some of them are is useful data. Sorry about the slightly haphazard way I've handled this so far this year, I'm still trying to work out where to draw the boundaries with the new rules. Andrew On Fri, May 3, 2013 at 8:57 AM, Nate Aune <nateja...@gmail.com> wrote: > > On Thursday, May 2, 2013 4:11:35 AM UTC-4, Andrew Godwin wrote: >> >> I feel like the deployment problem is one that cannot be solved in a mere >> 12 weeks and I'm not sure django-deployer is the right approach to >> encourage for this - it sits at the wrong level of abstraction and looks >> pretty fragile, and I'd be hesitant to put any sort of official emphasis on >> it without a lot of my qualms being answered. >> > > Could you elaborate on what your qualms are? I won't claim that it's a > work of art and I know there is lots of room for improvement, but please > remember that django-deployer is the result of two days of work, and it > already deploys Django projects to Dotcloud and Google App Engine with > almost minimal effort on the part of the user. Imagine what we can do in 12 > weeks! > > >> In particular, it appears to be sitting at the lowest-common-denominator >> level of the various feature sets and looks pretty immature. >> > > The initial goal of django-deployer was to reduce the barrier to entry for > someone new to Django who wants to quickly and easily get their Django > project running up on one of the PaaS providers. > So we started out with a minimum feature set which seems to cover the > non-production deployment needs for 80-90% of Django projects. > > We purposely omitted support for services such as Memcached, Celery, > email, cron jobs, etc. because we were trying to limit the scope at the > sprint and get a basic version working first. Now that the basic version is > working, we can look into adding support for these other services that > you'd most likely find in a production environment. > > I'm not sure I could accept this without a much clearer idea of what's >> going to happen and a very clear focus on what section of our user base it >> will help. Deployment isn't something there can be a single solution (or >> even pattern) for, and I think encouraging that could be a bad idea. >> > > Agreed. We're not attempting to make a one-size-fits-all solution, and > django-deployer will never claim to serve that purpose. But for > bootstrapping your Django project so that you can minimize the amount of > time it takes to try deploying your project to various PaaS providers, and > for demonstrating best practices when readying your project to be deployed, > I think it has a place in the Django ecosystem. > > I've looked at all the getting started docs from the various PaaS > providers, and many of them leave a lot to be desired. Many developers that > I've spoken with who've tried PaaS have thrown up their hands in > frustration when things don't work as advertised. This is largely the > impetus for starting the django-deployer project, to try to streamline this > process for those new to PaaS and Django deployment. > > Nate > > >> On Wed, May 1, 2013 at 8:20 PM, Nate Aune <nate...@gmail.com> wrote: >> >>> Hi Russell and Florian, >>> >>> A bit late to the party, but hopefully there's still time for this GSoC >>> proposal to be considered. I'm the maintainer of >>> django-deployer<http://natea.github.io/django-deployer/>. >>> It was initiated at the DjangoCon 2012 sprint and recently revisited at the >>> PyCon 2013 sprint. The overarching goal of django-deployer is to make it >>> easier to get Django deployed. So far the focus has been on deploying to >>> PaaS providers, because they require little to no sysadmin skills, and have >>> the added benefit of being free for small projects. >>> >>> django-deployer is the sister project PaaS Cheatsheet, a larger >>> documentation project that I've started recently. PaaS >>> Cheatsheet<http://www.paascheatsheet.com>is a guide for how to get a >>> Django/Python deployed on various PaaS >>> providers. >>> >>> The way django-deployer works is by asking a series of questions about >>> your Django project, and then generates a generic deploy.yml file that >>> captures all of your project's requirements. When you choose a particular >>> PaaS provider, django-deployer then translates the requirements defined in >>> the deploy.yml file and generates configuration files for that specific >>> PaaS provider. >>> >>> I met Colin (a student in Taiwan) at the PyCon sprint, and he was >>> responsible for single-handedly adding Google App Engine support to >>> django-deployer. He brought considerable expertise to our sprint team, and >>> shipped working code within a matter of hours. Since returning from PyCon, >>> we've been working remotely together, and he has continued to be a >>> dedicated contributor to the project. I have utmost confidence in his >>> abilities to add even more cool features and improve code quality of the >>> django-deployer tool if this project is accepted into GSoC. >>> >>> English is a second language for Colin, so he may have had some >>> difficulties in defending his proposal, so please allow me to step in and >>> clarify a few things. >>> >>> >>>> Firstly, I'm not familiar with Django-deploy; but from a quick >>>> inspection of the project page it doesn't appear that anyone in the Django >>>> core team is on the committee list. In order for you to have this proposal >>>> accepted as part of the GSoC, you'll need to secure agreement from the >>>> project maintainers of Django-deploy that they want the help your offering, >>>> that your project proposal is sound, and that they're willing to commit to >>>> applying any patches you produce. >>> >>> >>> As stated above, I'm willing to work closely with Colin to meet the >>> objectives described in the proposal. >>> >>> Secondly, you haven't provided any timelines for your proposal. My >>>> immediate reaction is that you're proposing a lot of work for a student to >>>> complete in 12 weeks. For example, writing a fully tested and documented >>>> database backend strikes me as a 12 week project in itself - yet this is >>>> apparently just one line item in one part of your project proposal. >>>> >>> >>> I think you may have misread that part of proposal. He's not proposing >>> to write a database backend. There is already one provided by the Google >>> App Engine >>> SDK<https://developers.google.com/appengine/docs/python/cloud-sql/django#usage>, >>> so we're simply incorporating that into the configuration scripts (i.e. >>> adding a settings_appengine.py that substitutes the DATABASE setting >>> value). >>> >>>> >>>> Lastly, your project proposal is very light on details. You're >>>> proposing a lot of ideas, but you haven't really specified anything beyond >>>> "I'm going to do it". Are there APIs that need to be specified? If, in the >>>> case of something like a database backend, the APi is already specified, >>>> are there going to be any complications in satisfying the API? We need a >>>> lot more detail before we will be able to judge if you understand the >>>> project your proposing, or if you are just proposing a bunch of ideas but >>>> haven't given those ideas any more thought than "this sounds interesting" >>>> >>> >>> I think the draft proposal was intended to get initial feedback and was >>> intentially light on details. Colin and I can work on specifying more >>> details on the actual deliverables within the next couple of days. We've >>> already posted some ideas for improving it to the Github issue tracker: >>> https://github.com/natea/**django-deployer/issues?state=**open<https://github.com/natea/django-deployer/issues?state=open> >>> >>> >You list "Refactor for Expandability" as last on your schedule. I think >>> it should be at the start, eg compare different solutions like GAE, heroku, >>> Gondor, find a >common subset and then write the backends accordingly. I >>> fear that if you do this the other way around you will have to throw away >>> most of the code for >heroku/GAE and rewrite it. >>> >>> That's essentially what we've started to do on the PaaS cheatsheet site. >>> One interesting side benefit of looking at all the PaaS providers, is that >>> we've able to identify the commonalities among them. >>> >>> >>> >* Regarding storage stuff, you say "I chose Google Cloud Storage >>> according to the networking speed and authorization flow will be easier >>> than using other >storage service such as S3.". Personally I don't think >>> it's wise to choose the easier storage (network speed should be no concern >>> here anyways), your API >should be able to allow to hook in the more >>> complex authorization flow too, what would be a better way to test your API >>> than using S3 :) >>> >>> I agree. It should be possible for the user to specify S3 as a storage >>> for static assets. But I think Colin does have a point that if you're >>> already going with Google App Engine, it makes sense to stick with other >>> Google technologies for the storage of the assets. Obviously, if you're >>> using Heroku you'd use S3 for that. >>> >>> >>> >All in all this proposal imo tries to address way to much and focuses >>> to much on Google. It would be more useful to lay the groundwork for an API >>> instead. That >said, did you get in contact with the project authors about >>> mentorship (eg are they interested and do have the time for it), I am >>> pretty sure none of the core devs >uses django-deployer, so mentoring it >>> would be a bit suboptimal. >>> >>> I agree that Colin's draft proposal was too focused on Google, but I >>> think that's simply because that is what he is most familiar with. As his >>> mentor, I would guide him to adding support for the other providers >>> (Heroku, OpenShift, Gondor, etc.) as we have already done for Dotcloud and >>> Stackato. >>> >>> Judging from all the Django deployment talks at meetups around the >>> country, it's fairly evident that deployment is and continues to be a hot >>> topic, one that is often a stumbling block for people new to Django. I >>> think Django would benefit greatly from tools such as django-deployer that >>> minimize the friction, and give people an easy path to painless deployments. >>> >>> Nate >>> >>>> >>>> On Sunday, April 21, 2013, LittleQ@NCCU, Taiwan wrote: >>>> >>>>> to django-developers: >>>>> >>>>> Sorry, I use Google Drive for proposing, and I original tend to >>>>> copy&paste it to here but found it will get in a mess. >>>>> >>>>> so I put my proposal here: >>>>> http://goo.gl/xJyJ9 >>>>> >>>>> My idea is to contribute to django-deployer and make some significant >>>>> improvements for it. >>>>> This proposal is still editing, but I pre-post it to prevent I'm >>>>> thinking it in the wrong way. >>>>> >>>>> any questions or any advise are welcome, thank you, I'm really a big >>>>> Django fan, and I hope I can make it better. >>>>> >>>>> cuz seems like there's no #django-dev, so feel free to add my XMPP >>>>> directly. >>>>> >>>>> it's open for messaging anytime :D >>>>> >>>>> >>>>> - Colin Su >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Django developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to django-developers+unsubscribe@****googlegroups.com. >>>>> To post to this group, send email to django-developers@**googlegroups* >>>>> *.com. >>>>> Visit this group at http://groups.google.com/**group** >>>>> /django-developers?hl=en<http://groups.google.com/group/django-developers?hl=en> >>>>> . >>>>> For more options, visit >>>>> https://groups.google.com/**grou**ps/opt_out<https://groups.google.com/groups/opt_out> >>>>> . >>>>> >>>>> >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@**googlegroups.com. >>> To post to this group, send email to django-d...@**googlegroups.com. >>> >>> Visit this group at http://groups.google.com/** >>> group/django-developers?hl=en<http://groups.google.com/group/django-developers?hl=en> >>> . >>> For more options, visit >>> https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out> >>> . >>> >>> >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
