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. In particular, it appears to be sitting at the lowest-common-denominator level of the various feature sets and looks pretty immature.
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. Andrew On Wed, May 1, 2013 at 8:20 PM, Nate Aune <[email protected]> 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 > > >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/**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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
