Hi all,
As promised, I have been working on the formalizing Meta task.
I apologize to not have posted in the last days, but I have come back with
my proposal. I want to post this now to the community, in order to gain
feedback and re-iterate.
Formalizing Meta
Enabling users to build custom stores that work well with Django
https://docs.google.com/document/d/1yp2_skqkxyrc0egdRv6ofnRGCI9nmvxDFBkCXgy0Jwo/edit#
Kind regards,
Daniel
On Tuesday, March 11, 2014 10:48:43 PM UTC, Daniel Pyrathon wrote:
>
> Hi Russel,
>
> Sorry for getting back now (I did not have notifications set up!). Thank
> you very much for the suggestions, I will have a look at models/options.py
> right away.
>
> Regards,
> Daniel Pyrathon
>
> On Thursday, March 6, 2014 12:03:04 AM UTC, Russell Keith-Magee wrote:
>>
>> Hi Daniel,
>>
>> On Wed, Mar 5, 2014 at 11:48 PM, Daniel Pyrathon <[email protected]>wrote:
>>
>>> Hi,
>>>
>>> My name is Daniel Pyrathon. I am currently a third year BSc student in
>>> Computer Science at the University of Plymouth.
>>>
>>> I love programming and I have always been active in the Open Source
>>> community (especially Python). In the past years I have written lots of
>>> Python, Javascript, Ruby, Java, and I am currently using C++ for many
>>> university projects. I have attended the last 3 EuroPython conferences and
>>> I have been a staff member of the conference for the last 2 years.
>>>
>>> I am currently looking for a way to contribute to Django. Working on
>>> Django would increase my knowledge of the framework as well as let me share
>>> my own experience.
>>>
>>> Reading the ideas list I found 2 of them that are very interesting for
>>> me, and so the reason behind this post is not only to present myself but
>>> also to discuss their feasibility.
>>>
>>> Formalizing the Meta object
>>>
>>> This task is very challenging because it digs in the internals of
>>> Django. I feel that I could learn a lot from it because I am very committed
>>> to refactoring and write most of my code in TDD. I have also experience
>>> with backwards compatibility.
>>>
>>> Do you have any resources (code) I should read to get up to date and to
>>> understand better how it is currently implemented?
>>>
>>
>> Unfortunately not; at least, not other than just trying to untangle the
>> mess that is django/db/models/options.py and the things that depend on it
>> (ModelForms and Admin in particular). This project really is the very model
>> of untangling a ball of string. The reason it's listed as a potential
>> project is specifically *because* there are no resources we can point you
>> at.
>>
>> If, after looking at the code, you feel it's a little "thin" for 12
>> weeks, one way to bulk it out is to build a proof of concept alternate
>> implementation of Meta. Aside from the "it would be good to document this"
>> aspect, the practical reason for wanting to formalise Meta is that it would
>> allow people to build duck-typed implementations of Meta. If you can build
>> an alternate implementation of the Meta interface, then you should be able
>> to deploy your "duck" into a Django project and build a ModelForm, or
>> browse it in Admin.
>>
>> So, for example, you could build a wrapper around a NoSQL store, or
>> around an LDAP or email store, that *looked* like a Django model from the
>> outside. This means you could view your NoSQL data, or LDAP records, or
>> emails in Admin without needing to go through a SQL database.
>>
>> The aim of proof of concept wouldn't be to commit something to Django's
>> core - it would be to build an external, standalone proof-of-concept,
>> demonstrating that your documentation was complete and correct. Depending
>> on what backend you choose, it might turn into a fully viable project on
>> it's own.
>>
>>
>>> Improved error reporting
>>>
>>> The idea of making people’s lives better by improving error messages is
>>> fundamental. There would be a lot to discuss: what type of imports would we
>>> want to mask? I have read BetterErrorMessages and would be happy to get
>>> started soon. My idea behind this task would be to expand on this ticket:
>>> what would be great is to add a web console with live REPL support, similar
>>> to what Werkzeug debugger does. This could be a great starting point and
>>> would lead to a better use of Django.
>>>
>>
>> This is an interesting idea; however, I see two problems:
>>
>> 1) It would involve reinventing the wheel. Werkzeug exists, and does its
>> job well; a GSoC project to "duplicate Werkzeug" doesn't strike me as a
>> good use of GSoC resources. However, a project to integrate Werkzeug's live
>> debugging capabilities into Django might be more viable.
>>
>> 2) Security implications. Unfortunately, more than one site has been
>> launched with debug=True accidentally left on; all you need to do then is
>> stimulate a server error, and you have REPL shell access to the server.
>> This strikes me as a remarkably effective foot-gun :-) Before you get too
>> involved in the implementation, I'd want to know the security issues have
>> been locked down.
>>
>>
>>> Said this, I have to be very honest. I have never contributed to Django
>>> up till now and I want to hear your feedback on which proposal would suit
>>> me best. However I learn a lot through experience and I am attracted by
>>> new and challenging tasks.
>>>
>>
>> My suggestion would be that the Meta project is probably better suited to
>> a newcomer. The Error reporting project is a little vague - it relies on
>> someone having a bit of experience with Django to know when the errors that
>> are being returned are unhelpful. A "green" Django user *could* do this,
>> but they're going to spend a lot more time trying to find problems that
>> need to be fixed.
>>
>> Approaching the project from the Werkzeug angle is an interesting idea,
>> but you're not starting with a pre-blessed project -- your first step is to
>> convince the core team that the idea is worth pursuing. Given the
>> compressed timeframe for submitting applications, it might not be possible
>> to get this blessing before your application is due.
>>
>>
>>> Also, it would be nice if I could have some suggestions on what to read
>>> and if there are some specific parts of the code I should be directed to.
>>>
>>
>> The best advice I can give is to dig in and get your hands dirty. Start
>> small. Look for a little bug; preferably one that is tangentially related
>> to your area of interest (try and fix a bug in ModelForms, for example).
>> Every little bit of experience will help, and along the way, you'll get to
>> know people in the development community, and Django's development process.
>>
>> Best of luck with you GSoC application!
>>
>> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/d36a6e61-26ea-41ea-9a0c-6a1ebd452372%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
