Re: Proposal: ModelForm API improvements
+1 This would be great. On Thursday, March 7, 2013 12:42:29 PM UTC-7, Bruno Renié wrote: > > Hello, > > There was some discussion on the current limitations of the ModelForm > API in the past couple of days on IRC, I'd like to make a proposal to > address some of them. > > I wrote django-floppyforms, a library that lets you render forms using > templates instead of python code. It behaves exactly like the Django > forms library, the only difference is the import path. Import > `floppyforms as forms` and when you render a form, the HTML code comes > from templates. > > There is still a limitation with ModelForms: since there is no way to > globally override the model field -> form field/widget mapping since > ModelForms fields come from the model definition. I documented this > here: > > > http://django-floppyforms.readthedocs.org/en/latest/differences.html#modelforms > > > It is possible to override widgets using the Meta.widgets dict but not > in a way that would switch all the ModelForm's fields to > template-based widgets automatically. The idea is to have custom > ModelForm subclasses with specific strategy on the model field -> form > field mapping. > > This is currently possible using something called `formfield_callback` > as a ModelForm class attribute: it is simply a callback that takes a > db field and returns a form field. But this callback is a) private and > b) limited: it gets lost in the inheritance chain as described in > ticket #12915: > > https://code.djangoproject.com/ticket/12915 > > A discussion thread was started a couple of days ago for a design > decision about formfield_callback: should we consider its behaviour as > buggy or leave it as it is? In fact formfield_callback is only used by > the admin, which has custom widgets for pretty much every db field. > This customization is done using the following methods and attributes > (all in django/contrib/admin/options.py): > > FORMFIELD_FOR_DBFIELD_DEFAULTS > ModelAdmin.formfield_overrides > ModelAdmin.formfield_for_dbfield(db_field, **kwargs) > ModelAdmin.formfield_for_choicefield(db_field, **kwargs) > ModelAdmin.formfield_for_foreignkey(db_field, **kwargs) > ModelAdmin.formfield_for_manytomany(db_field, **kwargs) > > In most cases those methods end up calling formfield() on the DB field > object, with some arguments for customizing the field class (wrongly > called `form_class`) and its constructor arguments (widget, label, > help_text, required, etc). > > The arguments to db_field.formfield() are passed via the > formfield_callback function I mentioned earlier. > > My proposal is to move that field customization API from the > ModelAdmin class back to ModelForm: > > * Move formfield_for_* to ModelForm and document them as public APIs > * Deprecate `formfield_callback` > * Write an AdminModelForm class that implements all the admin form > fields and widgets customization > * Modify ModelAdmin to make use of that base class > * (maybe?) deprecate ModelForm.Meta.widgets in favor of something > similar to the admin's formfield_overrides, which is more generic. > > I see the following advantages to this: > > * This would allow people to have "site-wide" fields/widgets > overrides, which is a feature that the admin is already proving > useful. Write a nice date picker once, register it for all your > DateFields globally. > > * Maintainers of form libraries can ship a base ModelForm class that > implements custom fields/widgets while keeping API compatibility with > Django. > > Backwards-compatibility shouldn't be an issue as this touches only a > couple of ModelAdmin methods. Regarding formfield_callback, despite it > being a private API I'm not sure it can be removed safely. There are > references to it on StackOverflow and on the Django bug tracker. > > I'm happy to work on a patch if core devs agree to accept this. Thoughts? > > Regards, > Bruno > -- 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.
Re: Proposal: deprecate and remove django.contrib.comments
On Thursday, March 7, 2013 10:18:11 PM UTC+5:30, Jacob Kaplan-Moss wrote: > > Hi folks -- > > This one's simple: I'd like to deprecate `django.contrib.comments`, > scheduling it to be removed in a couple of releases. [snipped] > Any objections? > As the student (back then) who worked on Jacob's code, I too have no objections and support the move to deprecate comments and translocate it into a separate repo. On a related note, can we also move a lot of the other contrib apps (except for auth and contentypes) into the separate repo? > > Jacob > -- 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.
Re: Django sanctioned extensions
On Fri, Mar 8, 2013 at 11:23 AM, wrote: > from thread "Moving database backends out of the core" > > On Mar 7, 2013, at 5:13 PM, Russell Keith-Magee > wrote: > > > There is, however, a possible middle ground, following the example set > by Flask: we introduce to Django a list of "officially recognised" > extensions. These extensions are still maintained as external projects, but > the core team promise to include these projects as part of the testing > regimen for a release. If the MSSQL backend were recognised like this, we > would run the full Django test suite against the MSSQL backend, and if that > testing revealed a bug in the test suite which was identified as being due > to a change in Django's codebase, that bug would be a release blocker (Bugs > in the backend itself would still be the backend's responsibility, and not > release blocking on Django) > > > > Looking outside database backends, this could also apply to high-profile > projects like haystack, django-registration, and so on. This would also > serve to highlight projects in our community that are 'defacto standards', > or good examples of reusability, without needing to expand the core team or > the size of contrib, and show that the core project is explicitly > interested in the broader ecosystem. > > I think this is a great idea. The backend testing makes sense to me (run > Django's tests). How does testing sanctioned apps work, though? You run > _their_ tests, and if they are caused by bugs in Django then they are > release blockers? > Caveat: I haven't given a huge amount of thought to this beyond the basic idea, so this is all my initial thoughts. I can see three options: 1) We run the tests. This requires that we come up with a standard for describing how test environments work. This could be as simple as requiring that python setup.py test works, and produces output in a known format. Requiring the use of tox, or Jenkins/Travis configs would be another option. 2) We leave running the tests up to individual projects, but require them to expose test results in a standard way. No idea how this would be specified, other than possibly a HTTP API endpoint. 3) We make it completely manual. This is something that only needs to happen around release time, so as long as it's relatively easy to run the full suite of tests manually, it may be possible to manually maintain a database of "working/not working". Option 3 might be the easiest way to get going - after all, you can always add automation infrastructure later. I really like the idea, and would like to help if I can. I imagine the leg > work will be mostly in setting up the testing infrastructure, although the > difficult part will be setting guidelines for and choosing apps that should > be in this group. Agreed that this is more a policy/procedures issue than a technical issue. I'm not sure what the best approach is for this - I'm open to suggestions. As for how to get this ball rolling -- well, I suppose there's two tasks that could be addressed immediately: * A list of candidate packages -- even if it's not the final approved list, we need somewhere to start * A first cut at a site to host this information. My local Django Users Group (in Perth, Western Australia) had some interesting discussions about this sort of packaging project at our last meeting; I'm hoping to start knocking together some code at our next meeting. As soon as we've got something to show off, I'll be sure to do so. 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.
Re: Proposal: deprecate and remove django.contrib.comments
On Fri, Mar 8, 2013 at 12:38 AM, Jacob Kaplan-Moss wrote: > On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee > wrote: >> However, I'd argue against using /dev/null as a disposal mechanism. I don't >> think the code should ever completely disappear. If someone offers to take >> over, that's great; but just because nobody volunteers to maintain the >> project, doesn't mean nobody is using the code. > > Yeah, that part was hyperbolic. I'll put it somewhere > (github.com/django/django-uncontrib-comments :) and invite anyone who > wants to maintain it to take it over. Late to the party, but +1 from me. Adrian -- 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.
Re: Proposal: deprecate and remove django.contrib.comments
Yep. +1 Val Sent from my mobile device. On 2013-03-07, at 11:48 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > This one's simple: I'd like to deprecate `django.contrib.comments`, > scheduling it to be removed in a couple of releases. > > My rationale is this: if you don't really care much about how comments > work but just want something easy, then Disqus (and its competitors) > are easier to use and have much better features (spam prevents, > moderation, etc.). If you want something complex and specific, on the > other hand, you're better off writing something from scratch. > > Practically, I'd do this by deprecating `django.contrib.comments` in > 1.6. We'd immediately stop making any changes to it (except for > security or data loss issues). It'd stay deprecated in 1.7, and would > be removed in 1.8. > > If someone volunteers to maintain it as an external project I'll move > the code to a new repo and direct people there in the docs. If nobody > volunteers, then it'll go to the great /dev/null in the sky. > > Any objections? > > Jacob > > -- > 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.
Re: Request for review: database-level autocommit
Hi Aymeric, On Friday, March 8, 2013 11:32:52 PM UTC+1, Aymeric Augustin wrote: > > Carl was kind enough to review the branch in detail. (Thank you!) > > I'll take his feedback into account, clean up the history, and push a new > version tomorrow. I hope to merge it during the week-end. > If you don't care about the timeframe I'd like to smoke test it on Postgresql, Mysql, Oracle on Tuesday (again -- due to an exam I won't have time for earlier tests [although I am pretty sure postgres and mysql are in a good shape after my previous tests]). In the worst case scenario I'd ask you to give me till the 16th. I'd also like to ask if we really want to have savepoints as default. Looking at my pluggable projects I'll usually have @atomic(savepoints=False) around __every__ complex view since I don't know if ATOMIC_REQUESTS will be true or false. Even if I use it as context manager most views won't care about transactions vs savepoints, so in most cases ensuring a transaction at all should be enough. Regards, Florian -- 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.
Re: Moving database backends out of the core
On Friday, March 8, 2013 3:35:53 PM UTC+1, Michael Manfre wrote: > > If we have MSSQL in core I'd really like to be able to talk with it from a > Linux machine too, it would also make testing easier since we'd just need a > VBox with MSSQL ;) Supporting a commercially available product but > requiring to run even more commercial software seems like counter intuitive > to me. > > Django needs a VBox running Windows for testing, regardless if MSSQL is in > the core. > That doesn't mean we actually have to support Microsoft in making MSSQL only accessible from Windows… Also there is a large difference between running a vm with a database server and running a vm (read: jenkins slaves) to execute tests. If Microsoft wants to use/support Django I guess they could easily publish a Python db-api 2.x driver. I'll happily code the Django part if the prerequisites would exist (assuming MSSQL actually does work ;))… Regards, Florian -- 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.
Re: Request for review: database-level autocommit
On 7 mars 2013, at 17:37, Aymeric Augustin wrote: > Barring unexpected problems and last minute vetoes, I plan to merge > this branch when another core dev reviews it thoroughly and accepts it, Carl was kind enough to review the branch in detail. (Thank you!) I'll take his feedback into account, clean up the history, and push a new version tomorrow. I hope to merge it during the week-end. -- Aymeric. -- 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.
Re: Moving database backends out of the core
On Fri, Mar 8, 2013 at 9:33 AM, Javier Guerra Giraldez wrote: > On Fri, Mar 8, 2013 at 4:25 AM, VernonCole wrote: > > People tend to think of ADO as only talking to Microsoft databases. > Nothing > > could be farther from the truth. When maintaining adodbapi, I normally > test > > against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and > postgres. > > I have also personally used it to get data from IBM DB2, an Active > Directory > > server, and a .csv file. If some idiot has written an odbc driver for > it, I > > will let you read it from Python. > > > nice. > > does the client run on non-win32 plaforms? from a cursory read of the > website, adodbapi seems to require pywin32. > adodbapi is included with pywin32 and requires it. Regards, Michael Manfre -- 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.
Re: Moving database backends out of the core
On Fri, Mar 8, 2013 at 6:35 AM, Florian Apolloner wrote: > What's the state of http://code.google.com/p/pymssql/ ? > Their stable release relies upon a no longer supported Microsoft driver and has some known issues that make it unusable (lack of MARS support being the biggest issue encountered in production). They've been working toward switching to FreeTDS, but I have not actively followed their progress since last summer and don't know how close they are to the switch. I might be remembering incorrectly, but some of the issues with django-pyodbc's support of stored procedures might have been rooted in FreeTDS. I haven't reevaluated django-pyodbc for a few years because of its lack of support and the native client drivers available to django-mssql are faster. > If we have MSSQL in core I'd really like to be able to talk with it from a > Linux machine too, it would also make testing easier since we'd just need a > VBox with MSSQL ;) Supporting a commercially available product but > requiring to run even more commercial software seems like counter intuitive > to me. > Django needs a VBox running Windows for testing, regardless if MSSQL is in the core. Regards, Michael Manfre -- 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.
Re: Moving database backends out of the core
On Fri, Mar 8, 2013 at 4:25 AM, VernonCole wrote: > People tend to think of ADO as only talking to Microsoft databases. Nothing > could be farther from the truth. When maintaining adodbapi, I normally test > against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and postgres. > I have also personally used it to get data from IBM DB2, an Active Directory > server, and a .csv file. If some idiot has written an odbc driver for it, I > will let you read it from Python. nice. does the client run on non-win32 plaforms? from a cursory read of the website, adodbapi seems to require pywin32. -- Javier -- 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.
Re: Proposal: deprecate and remove django.contrib.comments
+1 Cheers, Thiago Avelino On Fri, Mar 8, 2013 at 10:19 AM, Richard Bronosky wrote: > Yes. Aymeric, you covered every point I wanted to make. > > Sent from my Samsung Galaxy S3 using the Swype software keyboard. > --Richard Bronosky > On Mar 7, 2013 12:00 PM, "Aymeric Augustin" < > aymeric.augus...@polytechnique.org> wrote: > >> On 7 mars 2013, at 17:48, Jacob Kaplan-Moss wrote: >> >> > This one's simple: I'd like to deprecate `django.contrib.comments`, >> > scheduling it to be removed in a couple of releases. >> >> +1 >> >> > My rationale is this: if you don't really care much about how comments >> > work but just want something easy, then Disqus (and its competitors) >> > are easier to use and have much better features (spam prevents, >> > moderation, etc.). If you want something complex and specific, on the >> > other hand, you're better off writing something from scratch. >> >> The mere existence of django.contrib.comments implies that it's the >> sanctioned way to add comments to a Django application, but in 2013 >> it's most likely not going to be the right answer. Leaving it in contrib >> is a disservice to many developers using Django. >> >> Even www.djangoproject.com stopped using d.c.comments in 2009. >> >> > If someone volunteers to maintain it as an external project I'll move >> > the code to a new repo and direct people there in the docs. If nobody >> > volunteers, then it'll go to the great /dev/null in the sky. >> >> Even if no one volunteers to maintain it, I'd still consider putting it on >> life support somewhere under github.com/django. The goal is to >> provide an easier upgrade path for maintainers of websites currently >> using it. >> >> Otherwise we'll have people stuck at the last version of Django that >> still contains d.c.comments. >> >> -- >> Aymeric. >> >> >> >> -- >> 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. > > > -- 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.
Re: Proposal: deprecate and remove django.contrib.comments
Django should have a boneyard. Here is the homebrew boneyard https://github.com/Homebrew/homebrew-boneyard Sent from my Samsung Galaxy S3 using the Swype software keyboard. --Richard Bronosky On Mar 7, 2013 7:39 PM, "Jacob Kaplan-Moss" wrote: > On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee > wrote: > > However, I'd argue against using /dev/null as a disposal mechanism. I > don't > > think the code should ever completely disappear. If someone offers to > take > > over, that's great; but just because nobody volunteers to maintain the > > project, doesn't mean nobody is using the code. > > Yeah, that part was hyperbolic. I'll put it somewhere > (github.com/django/django-uncontrib-comments :) and invite anyone who > wants to maintain it to take it over. > > Jacob > > -- > 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.
Re: Proposal: deprecate and remove django.contrib.comments
Yes. Aymeric, you covered every point I wanted to make. Sent from my Samsung Galaxy S3 using the Swype software keyboard. --Richard Bronosky On Mar 7, 2013 12:00 PM, "Aymeric Augustin" < aymeric.augus...@polytechnique.org> wrote: > On 7 mars 2013, at 17:48, Jacob Kaplan-Moss wrote: > > > This one's simple: I'd like to deprecate `django.contrib.comments`, > > scheduling it to be removed in a couple of releases. > > +1 > > > My rationale is this: if you don't really care much about how comments > > work but just want something easy, then Disqus (and its competitors) > > are easier to use and have much better features (spam prevents, > > moderation, etc.). If you want something complex and specific, on the > > other hand, you're better off writing something from scratch. > > The mere existence of django.contrib.comments implies that it's the > sanctioned way to add comments to a Django application, but in 2013 > it's most likely not going to be the right answer. Leaving it in contrib > is a disservice to many developers using Django. > > Even www.djangoproject.com stopped using d.c.comments in 2009. > > > If someone volunteers to maintain it as an external project I'll move > > the code to a new repo and direct people there in the docs. If nobody > > volunteers, then it'll go to the great /dev/null in the sky. > > Even if no one volunteers to maintain it, I'd still consider putting it on > life support somewhere under github.com/django. The goal is to > provide an easier upgrade path for maintainers of websites currently > using it. > > Otherwise we'll have people stuck at the last version of Django that > still contains d.c.comments. > > -- > Aymeric. > > > > -- > 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.
Django sanctioned extensions
from thread "Moving database backends out of the core" On Mar 7, 2013, at 5:13 PM, Russell Keith-Magee wrote: > There is, however, a possible middle ground, following the example set by > Flask: we introduce to Django a list of "officially recognised" extensions. > These extensions are still maintained as external projects, but the core team > promise to include these projects as part of the testing regimen for a > release. If the MSSQL backend were recognised like this, we would run the > full Django test suite against the MSSQL backend, and if that testing > revealed a bug in the test suite which was identified as being due to a > change in Django's codebase, that bug would be a release blocker (Bugs in the > backend itself would still be the backend's responsibility, and not release > blocking on Django) > > Looking outside database backends, this could also apply to high-profile > projects like haystack, django-registration, and so on. This would also serve > to highlight projects in our community that are 'defacto standards', or good > examples of reusability, without needing to expand the core team or the size > of contrib, and show that the core project is explicitly interested in the > broader ecosystem. I think this is a great idea. The backend testing makes sense to me (run Django's tests). How does testing sanctioned apps work, though? You run _their_ tests, and if they are caused by bugs in Django then they are release blockers? I really like the idea, and would like to help if I can. I imagine the leg work will be mostly in setting up the testing infrastructure, although the difficult part will be setting guidelines for and choosing apps that should be in this group. Ryan -- 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.
Re: Moving database backends out of the core
Hi, On Friday, March 8, 2013 4:24:00 AM UTC+1, Michael Manfre wrote: > > django-mssql is actively maintained and will be for at least the next few > years because it's used for my employer's production site that is critical > to business operations. The backend also supports stored procedures almost > to the same extent as a Windows business application. The only real > downside to the backend is that it only works on Windows, reducing its > usefulness to a much smaller, but growing, minority of Django users. > What's the state of http://code.google.com/p/pymssql/ ? If we have MSSQL in core I'd really like to be able to talk with it from a Linux machine too, it would also make testing easier since we'd just need a VBox with MSSQL ;) Supporting a commercially available product but requiring to run even more commercial software seems like counter intuitive to me. Regards, Florian -- 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.
Re: Moving database backends out of the core
I would love to volunteer for the project of MSSQL support. It happens that django-mssql uses a fork of my adodbapi v2.1 code. I pulled those changes back into the main branch of adodbapi (and did a lot of useful refactoring thanks to the good work done on the fork) at version 2.3. Apparently the announcement of that did not get to the right people, since the peek I just took shows the forked code still in use. The two major obstacles I can see to MSSQL support (either as part of the core or as a supported add-on) are: 1) lack of an MSSQL server and test bed which the maintainers can use on a regular basis. 2) django-mssql is not Python 3 ready. The first of those obstacles has already been addressed. The second is fairly easy. I suspect (not having examined the code) that most of the Python3 problems will be found in the old fork of adodbapi. If we simply change django-mssql to call the current version of adodbapi all of that goes away. The current version is already present on their Python library, I am sure, because it ships as part of pywin32, which is also a prerequisite for the V2.1 code. Yes, all of pywin32, including adodbapi, runs on Python 3 -- has done for years. Would there be a "market" for a supported version of django which runs MSSQL? Does the bear live in the woods??? Take, for example, my present employer. (I escaped from the "we are a strictly Microsoft shop" employer where I used to work.) We here at eHealth Africa use Ubuntu and postgres as much as possible. But it's not always possible. For example, part of the project I am working on now will use ArcGIS -- which only runs on Windows. Then one of our funding organizations (ever heard of the Gates Foundation?) required us to host a database on an MSSQL server. We bit the bullet, bought the licenses (it's their money, after all) and set up the SQL server. Do you think we want to use django on it? Huh? If it will help kill polio, we will use anybody's software. As to the question of moving MSSQL into the core, or moving the two Oracle dbs out of it (you do remember who owns MySQL?) -- I would suggest pulling all non-FOSS out. Would you accept my patches to the core? Of course not. and you should not: I don't know django well enough. Would you accept my patches to an MSSQL back end? I should hope so. There has been talk. from time to time, about extending django to have more multi-database capability. The changes that would be needed to run three different db engines from outside the core would easily extend to other engines. People tend to think of ADO as only talking to Microsoft databases. Nothing could be farther from the truth. When maintaining adodbapi, I normally test against MS-SQL Server, Microsoft "Jet" (a.k.a. ACCESS), MySQL, and postgres. I have also personally used it to get data from IBM DB2, an Active Directory server, and a .csv file. If some idiot has written an odbc driver for it, I will let you read it from Python. Build the hooks. -- Vernon Cole On Thursday, March 7, 2013 8:24:00 PM UTC-7, Michael Manfre wrote: > > > > On Thu, Mar 7, 2013 at 8:13 PM, Russell Keith-Magee < > rus...@keith-magee.com > wrote: > >> I completely agree with Jacob's analysis of the status quo, and I agree >> largely with his position on having MSSQL in the core. >> >> I'd have no problem seeing MSSQL in the core - it's at least as high >> profile as Oracle, and although the demand for a MSSQL backend is >> restricted to a particular subset of the community, there is at least >> *some* demand for it to exist. Having MSSQL in core would allow us to hold >> our head high and say we support Microsoft platforms. Microsoft is even a >> member of the DSF at this point, so they're at least notionally interested >> in Django as a platform. >> > > /slightly off topic > I didn't realize they were a DSF member. I have been wanting to set up > Jenkins to run the test suite on Windows with the ultimate goal of getting > its results added to ci.djangoproject.com. Knowing that Microsoft is a > DSF member will probably help gain access to a VM on Azure to make that a > reality. I've so far managed to get an introduction to a PM on one of the > Azure teams to help get a more direct answer to some Django, Windows, and > SQL problems that have been raised to my attention. > > /back on topic > > The maintenance burden is the problem. Historically, we've already had to >> *remove* a MSSQL backend because of bit rot (see [1]) - this isn't a >> pattern I want to repeat in the future. I don't want to add a backend to >> core unless I'm *certain* that it will see long term maintenance. >> >> [1] https://github.com/django/django/commit/c30a050e41 >> > > The demand for MSSQL would probably increase if it were included in core > because companies could be more confident about its ongoing support. > > There are three options for using MSSQL with Django; django-pyodbc, > django-mssql, or
Re: Proposal: deprecate and remove django.contrib.comments
Sorry, but -1 from me. Given the core premise that the job of a web application framework is to find the common features that many websites need to implement and make them easy to achieve, commenting definitely fits into this category. I run two sites that use Django comments heavily. Django comments were easy to implement, and work very well (though a layer of spam protection would be nice), and I have no desire to migrate years of historical comments to a 3rd party system, or to write my own system (given the choice, I would write my own). Yes, I could handle having comments moved out of core as long as they were maintained somewhere "official," but I don't quite see the necessity. Commenting is a feature that most sites need, so commenting seems like something that Django should provide. That's part of what "using a kick-ass framework" means to me. My .02, ./s -- 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.
