Re: Config file for startproject.

Thanks, Josh. * I thought the config (.djangorc) should be included in project template it's own. * bash alias is OK, but it's not easy to share this way with lots of developers like "Hey, when you start development, please type `alias mystartproject...` (so long)." anyway, I got it. I'll create

Re: Config file for startproject.

There are a couple of problems with this proposal IMO. 1) The .djangorc file would need to be somewhere on the file system (like ~/.djangorc), because you want it for the startproject command, it can't be deployed with startproject 2) It doesn't seem to provide that big a benefit 3) A simple

Config file for startproject.

Hi all. I propose a new feature `.djangorc`. It should be included in root of project template. You can write down configations for `startproject --template=...` ## Motivation I always use custom project template, but it requires a lot of arguments like... django-admin startproject

Re: MigrationTestCase

Interesting! I came up with the following today, but calling the 'migrate' command via 'call_command' (like in Sean's code) is probably cleaner?! """ Test (data) migrations in Django. This uses py.test/pytest-django (the `transactional_db` fixture comes from there), but could be easily

Re: 1.9 release planning

Done that in https://github.com/django/django/pull/4908 On Monday, June 22, 2015 at 1:35:19 PM UTC-4, Loïc Bistuer wrote: > > We can just leave RemovedInDjango20Warning as an alias (not a subclass) to > PendingDeprecationWarning in 1.8. As long as we don't refer to it in the > rest of the

Re: 1.9 release planning

We can just leave RemovedInDjango20Warning as an alias (not a subclass) to PendingDeprecationWarning in 1.8. As long as we don't refer to it in the rest of the codebase it isn't ambiguous. -- Loïc > On Jun 23, 2015, at 00:21, Collin Anderson wrote: > > People import

Re: 1.9 release planning

People import the warning in order to silence them, right? On Monday, June 22, 2015 at 1:19:51 PM UTC-4, Markus Holtermann wrote: > > +1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid > plan. I don't think any of the (Pending)DeprecationWarnings are much of > a public API.

Re: 1.9 release planning

+1 -- Going with 1.8, 1.9, 1.10, 1.11 (LTS), 2.0 sounds like a solid plan. I don't think any of the (Pending)DeprecationWarnings are much of a public API. I've never seen them in the wild. /Markus On Mon, Jun 22, 2015 at 11:20:52AM -0400, Michael Manfre wrote: +1. I really don't like the idea

Re: Proposal for a new key in settings.DATABASE dict

Nope, OPTIONS is not new configuration tool You can find more info https://docs.djangoproject.com/en/1.8/ref/settings/#std:setting-OPTIONS If you will have usage problems, please create new message in django-users IRC or mailing list, this mailing list is for development django itself.

Re: Proposal for a new key in settings.DATABASE dict

Thanks Andriy, I missed that, is this new in 1.8 ? Le lundi 22 juin 2015 17:06:46 UTC+2, Andriy Sokolovskiy (coldmind) a écrit : > > I think due to > https://github.com/django/django/blob/8047e3666b0b50bb04e6f16c2a4fb21ddfd5713f/django/db/backends/postgresql_psycopg2/base.py#L162 > > you can

Re: 1.9 release planning

+1. I really don't like the idea of 2.x being odd. On Mon, Jun 22, 2015 at 10:33 AM, Loïc Bistuer wrote: > Just when we thought we had a winner... I'd like to make a final proposal. > > Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by > introducing

Re: 1.9 release planning

It's okay with me. I don't think RemovedInDjango18Warning is much of a public API, but we can mention it's renaming in the minor release notes just in case. On Monday, June 22, 2015 at 10:33:47 AM UTC-4, Loïc Bistuer wrote: > > Just when we thought we had a winner... I'd like to make a final

Re: Proposal for a new key in settings.DATABASE dict

I think due to https://github.com/django/django/blob/8047e3666b0b50bb04e6f16c2a4fb21ddfd5713f/django/db/backends/postgresql_psycopg2/base.py#L162 you can set application_name as the part of OPTIONS while configuration of your database, so it will be passed to psycopg2.connect. понедельник,

Proposal for a new key in settings.DATABASE dict

Hi, Be aware I will never speak about Django application as often used in Django developpement, here the string **application_name** is not the name of a Django'app. PostgreSQL permits on connection to specify a string that represent the name of application that connect, useful to identify

Re: 1.9 release planning

Just when we thought we had a winner... I'd like to make a final proposal. Instead of delaying adoption of SemVer to 3.0 we could do so in 2.0 by introducing the 1.10 and 1.11LTS releases. The upside is that the new policy applies right away and we avoid the oddball 2.0 and 2.1 releases. It's

Re: Django Admin - list_display default value

On Monday, June 15, 2015 at 11:03:07 PM UTC+2, Shai Berger wrote: > > (I received the message I'm replying to here with an empty subject, and > detached from the thread. Google Groups being funny?) > Guess so, I didn't get an email from your reply either... that's why I responded this slowly.

Re: Any chances to see Django benefit from new Async features of Python 3.5 ?

This might interest you: https://gist.github.com/andrewgodwin/b3f826a879eb84a70625 On Saturday, June 20, 2015 at 4:48:59 PM UTC+6, Benj wrote: > > Hi, > are