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.
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
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 huma
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.
понедельник, 22
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 pro
+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 the 1.10 and 1.11LTS rele
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 s
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.
понедельн
+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 o
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. I'v
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 the warning in order to s
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 codeba
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 adopte
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 --templ
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 bas
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
16 matches
Mail list logo