Re: Writing some tests for new feature

I'll copy my reply from your django-users thread in case you didn't see it: There was some recent work done on allowing customizing the ping_google sitemap URL, but it wasn't completed: https://github.com/django/django/pull/3528 You could take inspiration from your tests from there. On Wednesd

Re: Writing some tests for new feature

It's quite possible this is an area which is untested - partly because when it was originally written we didn't have the mock library to prevent the external url call. Adding tests would be wonderful. Marc On 22 April 2015 at 17:29, ST LEON wrote: > I want to contribute one new feature to Djang

Re: Request for help: building a docker/vagrant platform for running Django's test suite

Thank you everyone for your interest. I spoke with Tim last night to start piecing together the strategy. The gameplan on my end is to start a repo that we can all work from and (in)formally define the high level strategy. I'll enter any work items as issues on the github repo and share the link

Writing some tests for new feature

I want to contribute one new feature to Django (doing this first time). I reading this and have one question. First, write tests. I want to improve work of ping_google()

Re: Request for help: building a docker/vagrant platform for running Django's test suite

I've had a bit of experience with Docker and docker-compose (formerly fig), as I wrote the RST docs for docker-py, then reformatted them to MD. (https://github.com/docker/docker-py/commits?author=micahhausler) I also wrote a container transformation library for converting docker-compose files t

Re: Pass exception to error handlers

On Wed, Apr 22, 2015 at 3:05 PM, Tim Graham wrote: > I have some concerns from a security standpoint. For example, some exception > messages are definitely not meant to be displayed to end users and may leak > server implementation details. For example: This is saying you can't have a gun because

Re: Pass exception to error handlers

Le mercredi 22 avril 2015 à 07:05 -0700, Tim Graham a écrit : > I have some concerns from a security standpoint. For example, some > exception messages are definitely not meant to be displayed to end > users and may leak server implementation details. For example: > > SuspiciousFileOperation( >

Re: User.username max_length 254

I actually migrated my site to 1.7 and added a custom user model very easily. Here's a gist with the code, https://gist.github.com/micahhausler/63636f26cc87bb966218, but essentially all I had to do was add a new user app, copy the Django AbstractUser code, and set the db_table to 'auth_user'.

Re: Pass exception to error handlers

I have some concerns from a security standpoint. For example, some exception messages are definitely not meant to be displayed to end users and may leak server implementation details. For example: SuspiciousFileOperation( 'The joined path ({}) is located outside of the base path ' 'compo

Re: Altering migration operations depending django.Version (3rd party apps)

makemigrations shouldn't automatically add model managers to migrations files. Did you opt them in with `use_in_migrations = True`? If so, I believe you have to drop compatibility with Django 1.7 (i.e. are you limited to the migrations feature set of the lowest version of Django you wish to sup

Re: Altering migration operations depending django.Version (3rd party apps)

Hi Tim If I create a migration on the lowest Django version I wish to support (say 1.7), it will not add the AlterModelManager operation to the migration. If someone installs the app on Django 1.8, the migration will run fine. However, every time the user runs "migrate" after that it will comp

Re: Altering migration operations depending django.Version (3rd party apps)

The recommended way is to run makemigrations with the lowest version of Django you wish to support. As this recommendation hasn't been tested, let us know if you encounter any problems with it. A potential problem that comes to mind is if you have an EmailField which had its default max_length

Altering migration operations depending django.Version (3rd party apps)

Hi all I'm creating a migration for a 3rd party app that needs to work with current and previous Django versions. In Django 1.8 "makemigrations" adds a "AlterModelManager" operation which only works with Django 1.8 and later since AlterModelManager didn't exist before. It will also do an AlterF

Re: Suggestions on a form library

You should use something like bitbucket or github. Did you check existing form libraries like django floppy forms or django crispy forms ? I think this belongs to django-users as well. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributio

Re: Pass exception to error handlers

I find this interesting too. It could be very useful when using custom exception in the model. On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz wrote: > > Here is some code to demonstrate a possible implementation: > > https://github.com/claudep/django/commit/5617d32e8f10861fb84bf2629

Re: Idea/request for help: Django Developers Community Survey

Great idea. The questions look good enough to me. I love django-apps or libraries shipped in python packages. One of the reason I love Django is the fact that it didn't frenetically add stuff to the framework just because it's cool. The good thing of python packages is that you can get some data

Re: virtual fields and the migration framework

Hi Markus, thank you very much for your suggestion. I'll try it later this afternoon and come back to report. Federico On Wednesday, April 22, 2015 at 12:54:32 AM UTC+2, Markus Holtermann wrote: > > Hey Federico, > > I just had a brief look at the code. If I understand > the HStoreVirtualMixi