Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Andrew Godwin]

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  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  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.
>>> 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, 

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Nate Aune]

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  > 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. 
>> 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 
>> Cheatsheetis 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 

Re: [GSoC 2013] contribute to django-deployer for deploying django to PaaS easily

[Nate Aune]

On Thursday, May 2, 2013 9:46:52 PM UTC-4, Jacob Kaplan-Moss wrote:

> While I share some of Andrew's concerns, I do think this is still a fairly 
> good topic for GSoC. 
>

Thanks for your vote of confidence! :) We'd love to get your input on how 
to address Andrew's concerns. We've already started looking into replacing 
the manage.sh script with Django management commands, so you can deploy 
using the familiar manage.py (which is something that I think you suggested 
awhile ago). 

I made a couple screencasts where you can see the tool in action, in it's 
current state of infancy:
http://appsembler.com/blog/deploy-django-apps-to-google-app-engine-with-django-deployer-in-5-minutes/
http://appsembler.com/blog/deploy-django-apps-to-dotcloud-with-django-deployer-in-5-minutes/
 

> However, I think the only way it could happen would be if Nate wants 
> to mentor the project; Nate, can you mentor? 


Yes! As I mentioned in my last post, I'm happy to serve as a GSoC mentor. I 
will do my best to provide guidance to Colin as we continue to shape 
django-deployer to be a useful tool for the Django community.
 

> If so, you should hook up  with Andrew and make sure you apply to be a 
> mentor so we can have you 
> added before the review process. 
>

I added my name to the wiki, and also signed up on the GSoC site 
here: http://www.google-melange.com/gsoc/connection/google/gsoc2013/nateaune/1

Nate

On Thu, May 2, 2013 at 4:11 AM, 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. 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  
> 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. 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 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 
> 

Re: Improve annotation and aggregation

[nimesh ghelani]

Hi Russell,

Thanks for the response.
Clearly I don't have enough time to prove my eligibility to pull it off. 
Guess I will hang around here outside GSoC and look forward to contributing 
till the extent of my capabilities :).

Regards,
Nimesh Ghelani

On Friday, May 3, 2013 7:00:33 AM UTC+5:30, Russell Keith-Magee wrote:
>
>
> On Fri, May 3, 2013 at 4:31 AM, nimesh ghelani 
>  > wrote:
>
>> Hey,
>> Will like reviews on my proposal
>>
>> https://gist.github.com/nims11/dbd2f52677377eb60c07
>>
>> Hi Nimesh,
>
> At present, this isn't an especially compelling proposal. 
>
> The bulk of what you're proposing is extremely vague. The #10929 default 
> NULL issue is well known and understood, but detail on your other proposal 
> goes no further than "should be simpler". We agree. Now, how are you going 
> to do that? You haven't given an API proposal, and you're not previously 
> known to the wider community, so we can't judge whether you have good API 
> design skills, or whether you've looked at any of the internals to 
> determine if what you're proposing is technically feasible given the 
> existing infrastructure. 
>
> On top of that, based on no experience with the query internals, you've 
> assumed that you'll be able to understand the internals of Django's query 
> engine, and then design and get consensus on an API plan in a 2 week 
> window. That's… ambitious. 
>
> Then you've got a 7 week block to implement this plan. This sort of 
> granularity gives us no confidence that you in any way understand the task 
> ahead of you. If you can't provide a plan at the granularity of days, or a 
> week at the *most*, then it's safe to say you haven't actually thought in 
> detail about the complexity of the problem you're proposing to solve.
>
> You're proposing a deep dive into the internals of Django's query 
> infrastructure. Committing to being a mentor for the GSoC is a big 
> commitment, and there is a limited number of people who are in a position 
> to mentor you on this project. When combined with the vagueness of what 
> you're proposing, you haven't exactly inspired the confidence you'll need 
> to convince someone to commit to mentoring you.
>
> If you want to be selected for the GSoC, you'll need to provide a lot more 
> details -- most importantly, evidence that you've thought about the problem 
> at a level beyond "this looks like a nice problem". 
>
> Yours,
> Russ Magee %-)
>
>

-- 
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.