Re: Config file for startproject.

[Hiroki Kiyohara]

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 some aliases or wrapper commands if it's
necessary.


On Tue, Jun 23, 2015 at 12:08 PM, Josh Smeaton 
wrote:

> 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 bash alias can achieve the exact same result
>
> I just don't think this is something that Django needs to take on when
> it's very easy to create your own alias that does exactly what you need.
>
> Regards,
>
>
> On Tuesday, 23 June 2015 12:38:24 UTC+10, Hiroki Kiyohara wrote:
>>
>> 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 --template=/path/to/template
>> --extension=py,md,rst,ini,cfg --name=.coveragerc 
>>
>> Actually I use this `startproject` feature to create 'repository
>> skeleton' not only django's project directory.
>> 'repository skeleton' contains like README.md, tox.ini, .coveragerc, and
>> django's project direcotry and so on.
>>
>> I know this usage of `startproject` is little tricky. but I think some of
>> django users use like this and
>> want this `.djangorc` feature (not to pass a lot of argument).
>>
>> ## Proposal
>>
>> `.djangorc` will contain some of this.
>>
>> ```
>> [startproject]
>> extension=py,md,rst,ini,cfg
>> name=.coveragerc
>> ```
>>
>> and If some project template contains this file, startproject command
>> follow this config on creation process.
>>
>> How do you think about it?
>> It's just my idea and there's no implementation.
>> I want your feedback, thank you.
>>
>>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/mOMTohdfVOI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/c4da9a61-fc06-4992-acff-12db064c91de%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPYpbLUWr2sPtyS8V7KwrgbyBnxs-Mko%2B_3dendHY-y-a3eEhQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Config file for startproject.

[Josh Smeaton]

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 bash alias can achieve the exact same result

I just don't think this is something that Django needs to take on when it's 
very easy to create your own alias that does exactly what you need.

Regards,

On Tuesday, 23 June 2015 12:38:24 UTC+10, Hiroki Kiyohara wrote:
>
> 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 --template=/path/to/template 
> --extension=py,md,rst,ini,cfg --name=.coveragerc 
>
> Actually I use this `startproject` feature to create 'repository skeleton' 
> not only django's project directory.
> 'repository skeleton' contains like README.md, tox.ini, .coveragerc, and 
> django's project direcotry and so on.
>
> I know this usage of `startproject` is little tricky. but I think some of 
> django users use like this and
> want this `.djangorc` feature (not to pass a lot of argument).
>
> ## Proposal
>
> `.djangorc` will contain some of this.
>
> ```
> [startproject]
> extension=py,md,rst,ini,cfg
> name=.coveragerc
> ```
>
> and If some project template contains this file, startproject command 
> follow this config on creation process.
>
> How do you think about it?
> It's just my idea and there's no implementation.
> I want your feedback, thank you.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c4da9a61-fc06-4992-acff-12db064c91de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Config file for startproject.

[Hiroki Kiyohara]

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 --template=/path/to/template 
--extension=py,md,rst,ini,cfg --name=.coveragerc 

Actually I use this `startproject` feature to create 'repository skeleton' 
not only django's project directory.
'repository skeleton' contains like README.md, tox.ini, .coveragerc, and 
django's project direcotry and so on.

I know this usage of `startproject` is little tricky. but I think some of 
django users use like this and
want this `.djangorc` feature (not to pass a lot of argument).

## Proposal

`.djangorc` will contain some of this.

```
[startproject]
extension=py,md,rst,ini,cfg
name=.coveragerc
```

and If some project template contains this file, startproject command 
follow this config on creation process.

How do you think about it?
It's just my idea and there's no implementation.
I want your feedback, thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42de6942-9cf7-42cb-b120-1bd16235d484%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: MigrationTestCase

[Daniel Hahler]

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 adopted for Django's testrunner:

from django.test.testcases import TransactionTestCase

class FooTestcase(TransactionTestCase):
def test_with_django(self):
…

This example tests that some fields are properly migrated from a `Profile` model
to `User`.
"""

from django.db import connection
from django.db.migrations.executor import MigrationExecutor


def test_migrate_profile_to_user(transactional_db):
executor = MigrationExecutor(connection)
app = "YOUR_APP"
migrate_from = [(app, "000X_before")]
migrate_to = [(app, "000X_after")]

executor.migrate(migrate_from)
old_apps = executor.loader.project_state(migrate_from).apps

# Create some old data.
Profile = old_apps.get_model(app, "Profile")
old_profile = Profile.objects.create(email="email",
 firstname="firstname",
 lastname="lastname")
# Migrate forwards.
executor.loader.build_graph()  # reload.
executor.migrate(migrate_to)
new_apps = executor.loader.project_state(migrate_to).apps

# Test the new data.
Profile = new_apps.get_model(app, "Profile")
User = new_apps.get_model(app, "UserEntry")
assert 'firstname' not in Profile._meta.get_all_field_names()

user = User.objects.get(email='email')
profile = Profile.objects.get(user__email='email')
assert user.profile.pk == old_profile.pk == profile.pk
assert profile.user.email == 'email'
assert profile.user.first_name == 'firstname'
assert profile.user.last_name == 'lastname'
 


https://gist.github.com/blueyed/4fb0a807104551f103e6


Cheers,
Daniel.

Am Donnerstag, 7. Mai 2015 12:02:12 UTC+2 schrieb Tom Linford:
>
> At Robinhood, we've been using a custom in-house MigrationTestCase for 
> testing migrations that we'd like to contribute, but want to check the API 
> of it before contributing it. Here's the definition of the class:
>
> class MigrationTestCase(TransactionTestCase):
> """
> app_label: name of app (ie. "users" or "polls")
> (start|dest)_migration_name: name of migration in app
> (e.g. "0001_initial")
> additional_dependencies: list of tuples of `(app_label, 
> migration_name)`.
> Add any additional migrations here that need to be included in the
> generation of the model states.
>
> Usage:
>
> class TestCase(MigrationTestCase):
> app_label = ...
> start_migration_name = ...
> dest_migration_name = ...
> additional_dependencies = ...
>
> def setUp(self):
> # Create models with regular orm
> super(TestCase, self).setUp()
> # Create models with start orm. Access model with:
> # self.start_models[""][""]
> # Note that model_name must be all lower case, you can just do:
> # ._meta.model_name to get the model_name
>
> def test(self):
> # Still using start orm
> self.migrate_to_dest()
> # Now, you can access dest models with:
> # self.dest_models[""][""]
> """
> app_label = None
> start_migration_name = None
> dest_migration_name = None
> additional_dependencies = []
>
>
> Let me know if this API is agreeable and I can make a PR for this feature.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10e51c46-3aff-4ee5-bbb0-889112c6a2b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

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 codebase it isn't ambiguous. 
>
> -- 
> Loïc 
>
> > On Jun 23, 2015, at 00:21, Collin Anderson  > wrote: 
> > 
> > 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'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 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 releases. 
> > >> 
> > >> The upside is that the new policy applies right away and we avoid the 
> > >> oddball 2.0 and 2.1 releases. 
> > >> 
> > >> It's much less invasive than the previous idea of renaming 1.9 to 
> 2.0, but 
> > >> it still requires renaming PendingDeprecationWarnings in 1.8, and 
> both 
> > >> warnings in 1.9. 
> > >> 
> > >> What do you think? 
> > >> 
> > >> -- 
> > >> Loïc 
> > >> 
> > >> > On Jun 17, 2015, at 08:47, Josh Smeaton  
> wrote: 
> > >> > 
> > >> > I'm also +1 on the proposal as it stands, and neutral on when the 
> semver 
> > >> versioning should begin. 
> > >> > 
> > >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> > >> > I'm +1 on the Google doc proposal and like Markus, I support 
> relabeling 
> > >> 1.9 to 2.0 to line the versions up with the new paradigm without the 
> X.1 
> > >> LTS oddball. 
> > >> > 
> > >> > Regards, 
> > >> > Michael Manfre 
> > >> > 
> > >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson <
> cmawe...@gmail.com> 
> > >> wrote: 
> > >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 
> 3.1, 
> > >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and 
> we 
> > >> sacrifice a little bit of strict semver, but it give some nice 
> meaning to 
> > >> the version numbers. 
> > >> > 
> > >> > 
> > >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> > >> > Thanks Loïc, 
> > >> > 
> > >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > >> > > I've attempted to summarize the history of this thread. Note that 
> I 
> > >> > > marked as +1 any generally positive feedback towards a given 
> > >> > > proposal, please correct if you feel misrepresented. 
> > >> > > 
> > >> > [snip] 
> > >> > > 
> > >> > > # Third iteration: 
> > >> > > 
> > >> > > 5/ Switching to Semantic Versioning 
> > >> > > 
> > >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > >> > > proposal were made to reconcile it with our release policy. So 
> far 
> > >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive 
> feedback to 
> > >> > > various proposals in that direction but I don't think we have yet 
> > >> > > reached consensus on a specific one. Tim updated the Google doc 
> to 
> > >> > > reflect my latest proposal, so including me that's 2 formal +1 
> for 
> > >> > > it, but I'd say we should wait for at least a couple more votes 
> > >> > > before taking it to the technical board. 
> > >> > > 
> > >> > > Refs: - http://semver.org/ - Carl's analysis 
> > >> > > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > >> > > 
> > >> > > 
> > >> > - Ryan's proposals 
> > >> > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > >> > > - Loïc's proposal 
> > >> > > 
> > >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> > >> > 
> > >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> > >> > Google doc. 
> > >> > 
> > >> > I was trying to come up with a proposal where LTS == major release 
> for 
> > >> > the sake of argument, since it seemed like that was intuitive to at 
> > >> > least some people, but it's not worth the required lengthening of 
> > >> > deprecation paths. Your proposal is much better. (And it does make 
> some 
> > >> > intuitive sense for the _last_ minor release in a major series to 
> be LTS 
> > >> > rather than the first). 
> > >> > 
> > >> > Carl 
> > >> > 
> > >> > 
> > >> > -- 
> > >> > You received this message because you are subscribed to the Google 
> > >> Groups "Django developers (Contributions to Django itself)" group. 
> > >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> > >> an email 

Re: 1.9 release planning

[Loïc Bistuer]

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 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'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 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 releases. 
> >> 
> >> The upside is that the new policy applies right away and we avoid the 
> >> oddball 2.0 and 2.1 releases. 
> >> 
> >> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but 
> >> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> >> warnings in 1.9. 
> >> 
> >> What do you think? 
> >> 
> >> -- 
> >> Loïc 
> >> 
> >> > On Jun 17, 2015, at 08:47, Josh Smeaton  wrote: 
> >> > 
> >> > I'm also +1 on the proposal as it stands, and neutral on when the semver 
> >> versioning should begin. 
> >> > 
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> >> > I'm +1 on the Google doc proposal and like Markus, I support relabeling 
> >> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 
> >> LTS oddball. 
> >> > 
> >> > Regards, 
> >> > Michael Manfre 
> >> > 
> >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
> >> wrote: 
> >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> >> sacrifice a little bit of strict semver, but it give some nice meaning to 
> >> the version numbers. 
> >> > 
> >> > 
> >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> >> > Thanks Loïc, 
> >> > 
> >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> >> > > I've attempted to summarize the history of this thread. Note that I 
> >> > > marked as +1 any generally positive feedback towards a given 
> >> > > proposal, please correct if you feel misrepresented. 
> >> > > 
> >> > [snip] 
> >> > > 
> >> > > # Third iteration: 
> >> > > 
> >> > > 5/ Switching to Semantic Versioning 
> >> > > 
> >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> >> > > proposal were made to reconcile it with our release policy. So far 
> >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> >> > > various proposals in that direction but I don't think we have yet 
> >> > > reached consensus on a specific one. Tim updated the Google doc to 
> >> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> >> > > it, but I'd say we should wait for at least a couple more votes 
> >> > > before taking it to the technical board. 
> >> > > 
> >> > > Refs: - http://semver.org/ - Carl's analysis 
> >> > > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> >> > > 
> >> > > 
> >> > - Ryan's proposals 
> >> > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> >> > > - Loïc's proposal 
> >> > > 
> >> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> >> > 
> >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> >> > Google doc. 
> >> > 
> >> > I was trying to come up with a proposal where LTS == major release for 
> >> > the sake of argument, since it seemed like that was intuitive to at 
> >> > least some people, but it's not worth the required lengthening of 
> >> > deprecation paths. Your proposal is much better. (And it does make some 
> >> > intuitive sense for the _last_ minor release in a major series to be LTS 
> >> > rather than the first). 
> >> > 
> >> > Carl 
> >> > 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> Groups "Django developers (Contributions to Django itself)" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, send 
> >> an email to django-develop...@googlegroups.com. 
> >> > To post to this group, send email to django-d...@googlegroups.com. 
> >> > 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> >>  
> >> . 
> >> > 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> >

Re: 1.9 release planning

[Collin Anderson]

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'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 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 releases. 
> >> 
> >> The upside is that the new policy applies right away and we avoid the 
> >> oddball 2.0 and 2.1 releases. 
> >> 
> >> It's much less invasive than the previous idea of renaming 1.9 to 2.0, 
> but 
> >> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> >> warnings in 1.9. 
> >> 
> >> What do you think? 
> >> 
> >> -- 
> >> Loïc 
> >> 
> >> > On Jun 17, 2015, at 08:47, Josh Smeaton  > wrote: 
> >> > 
> >> > I'm also +1 on the proposal as it stands, and neutral on when the 
> semver 
> >> versioning should begin. 
> >> > 
> >> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> >> > I'm +1 on the Google doc proposal and like Markus, I support 
> relabeling 
> >> 1.9 to 2.0 to line the versions up with the new paradigm without the 
> X.1 
> >> LTS oddball. 
> >> > 
> >> > Regards, 
> >> > Michael Manfre 
> >> > 
> >> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
>
> >> wrote: 
> >> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> >> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> >> sacrifice a little bit of strict semver, but it give some nice meaning 
> to 
> >> the version numbers. 
> >> > 
> >> > 
> >> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> >> > Thanks Loïc, 
> >> > 
> >> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> >> > > I've attempted to summarize the history of this thread. Note that I 
> >> > > marked as +1 any generally positive feedback towards a given 
> >> > > proposal, please correct if you feel misrepresented. 
> >> > > 
> >> > [snip] 
> >> > > 
> >> > > # Third iteration: 
> >> > > 
> >> > > 5/ Switching to Semantic Versioning 
> >> > > 
> >> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> >> > > proposal were made to reconcile it with our release policy. So far 
> >> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback 
> to 
> >> > > various proposals in that direction but I don't think we have yet 
> >> > > reached consensus on a specific one. Tim updated the Google doc to 
> >> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> >> > > it, but I'd say we should wait for at least a couple more votes 
> >> > > before taking it to the technical board. 
> >> > > 
> >> > > Refs: - http://semver.org/ - Carl's analysis 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> >> > > 
> >> > > 
> >> > - Ryan's proposals 
> >> > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> >> > > - Loïc's proposal 
> >> > > 
> >> 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> >> > 
> >> > FWIW, I am also +1 on your proposal, as currently documented in the 
> >> > Google doc. 
> >> > 
> >> > I was trying to come up with a proposal where LTS == major release 
> for 
> >> > the sake of argument, since it seemed like that was intuitive to at 
> >> > least some people, but it's not worth the required lengthening of 
> >> > deprecation paths. Your proposal is much better. (And it does make 
> some 
> >> > intuitive sense for the _last_ minor release in a major series to be 
> LTS 
> >> > rather than the first). 
> >> > 
> >> > Carl 
> >> > 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> Groups "Django developers (Contributions to Django itself)" group. 
> >> > To unsubscribe from this group and stop receiving emails from it, 
> send 
> >> an email to django-develop...@googlegroups.com. 
> >> > To post to this group, send email to django-d...@googlegroups.com. 
> >> > 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
>  
> >> . 
> >> > 
> >> > For more options, visit https://groups.google.com/d/optout. 
> >> > 
> >> > 
> >> > 
> >> > -- 
> >> > GPG Fingerprint: 74DE D158 BAD0 EDF8 
> >> > keybase.io/manfre 
> >> > 
> >> > -- 
> >> > You received this message because you are subscribed to the Google 
> >> Groups "Django 

Re: 1.9 release planning

[Markus Holtermann]

+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 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 releases.

The upside is that the new policy applies right away and we avoid the
oddball 2.0 and 2.1 releases.

It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
it still requires renaming PendingDeprecationWarnings in 1.8, and both
warnings in 1.9.

What do you think?

--
Loïc

> On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
>
> I'm also +1 on the proposal as it stands, and neutral on when the semver
versioning should begin.
>
> On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> I'm +1 on the Google doc proposal and like Markus, I support relabeling
1.9 to 2.0 to line the versions up with the new paradigm without the X.1
LTS oddball.
>
> Regards,
> Michael Manfre
>
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
wrote:
> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
sacrifice a little bit of strict semver, but it give some nice meaning to
the version numbers.
>
>
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc,
>
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > I've attempted to summarize the history of this thread. Note that I
> > marked as +1 any generally positive feedback towards a given
> > proposal, please correct if you feel misrepresented.
> >
> [snip]
> >
> > # Third iteration:
> >
> > 5/ Switching to Semantic Versioning
> >
> > Donald mentioned SemVer on IRC a few days ago. Since then various
> > proposal were made to reconcile it with our release policy. So far
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > various proposals in that direction but I don't think we have yet
> > reached consensus on a specific one. Tim updated the Google doc to
> > reflect my latest proposal, so including me that's 2 formal +1 for
> > it, but I'd say we should wait for at least a couple more votes
> > before taking it to the technical board.
> >
> > Refs: - http://semver.org/ - Carl's analysis
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> >
> >
> - Ryan's proposals
>
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > - Loïc's proposal
> >
https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
>
> FWIW, I am also +1 on your proposal, as currently documented in the
> Google doc.
>
> I was trying to come up with a proposal where LTS == major release for
> the sake of argument, since it seemed like that was intuitive to at
> least some people, but it's not worth the required lengthening of
> deprecation paths. Your proposal is much better. (And it does make some
> intuitive sense for the _last_ minor release in a major series to be LTS
> rather than the first).
>
> Carl
>
>
> --
> You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
.
>
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
>
> --
> You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com
.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"Django developers  (Contributions to Django itself)" 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-dev

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

[Andriy Sokolovskiy (coldmind)]

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.

понедельник, 22 июня 2015 г., 18:41:13 UTC+3 пользователь 
rodolphe.q...@people-doc.com написал:
>
> 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 set application_name as the part of OPTIONS while configuration of 
>> your database, so it will be passed to psycopg2.connect.
>>
>>
>> понедельник, 22 июня 2015 г., 17:56:16 UTC+3 пользователь 
>> rodolphe.q...@people-doc.com написал:
>>>
>>> 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 human tools like 
>>> *psql* or automated tools like *slony*, this optionnal parameter is 
>>> called *application_name*. This is very useful to debugging purpose, 
>>> postgresql prints this information in logs or internal view liek 
>>> pg_stat_activity, for example
>>>
>>> gatling=# select * from pg_stat_activity  limit 1 ;
>>> -[ RECORD 1 ]+--
>>> datid| 318636
>>> datname  | lolyx
>>> pid  | 8436
>>> usesysid | 16384
>>> usename  | rodo
>>> application_name | slon.local_listen
>>> client_addr  | ::1
>>> client_hostname  | 
>>> client_port  | 42918
>>> backend_start| 2015-06-16 20:31:50.177957+02
>>> xact_start   | 
>>> query_start  | 2015-06-22 16:25:57.494463+02
>>> state_change | 2015-06-22 16:25:57.494564+02
>>> waiting  | f
>>> state| idle
>>> backend_xid  | 
>>> backend_xmin | 
>>> query| rollback transaction;
>>>
>>> Ref : 
>>> http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-APPLICATION-NAME
>>>  
>>> http://www.postgresql.org/docs/9.4/static/libpq-connect.html#LIBPQ-CONNSTRING
>>>
>>>
>>> The welll known python driver for postgresql *psycopg2* permots to use 
>>> this functionnnality by using kwargs when openning connection as :
>>>
>>> conn = connect(database='foo', port='5435',
>>>host='127.0.0.1', user='rodo',password='rodo',
>>>application_name='foobar')
>>> le code ici
>>>
>>> Ref : http://initd.org/psycopg/docs/module.html
>>>
>>> But, actually Django doesn't permit to use this option, before proposing 
>>> a patch to implement this in future version of Django I would like to 
>>> receive your comments and idea about this feature.
>>> My first idea is to add an optionnal entry in settings.DATABASE as is :
>>>
>>> DATABASES 
>>>  
>>> This new key in DATABASE dict will not use by all backends, not only 
>>> PostgreSQL has this functionnality, AFAIK SQL Server permits this too.
>>>
>>> I'll read your comments with interest, this will be my first patch to 
>>> Django and I'll be happy to discuss things like what is an acceptable name 
>>> for this new entry ?
>>> And of course I'll read the Contritbuting to Django before make my PR.
>>>
>>> Is this feature is accepted, the next step will be to automatically set 
>>> this settiings when using the **shell**, **dbshell** or **shell_plus** 
>>> command to help identify human action on production systems !
>>>
>>> Regards,
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d3f93f5-0142-4bd1-b2b8-fac4ae96f144%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[rodolphe . quiedeville]

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 set application_name as the part of OPTIONS while configuration of 
> your database, so it will be passed to psycopg2.connect.
>
>
> понедельник, 22 июня 2015 г., 17:56:16 UTC+3 пользователь 
> rodolphe.q...@people-doc.com написал:
>>
>> 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 human tools like 
>> *psql* or automated tools like *slony*, this optionnal parameter is 
>> called *application_name*. This is very useful to debugging purpose, 
>> postgresql prints this information in logs or internal view liek 
>> pg_stat_activity, for example
>>
>> gatling=# select * from pg_stat_activity  limit 1 ;
>> -[ RECORD 1 ]+--
>> datid| 318636
>> datname  | lolyx
>> pid  | 8436
>> usesysid | 16384
>> usename  | rodo
>> application_name | slon.local_listen
>> client_addr  | ::1
>> client_hostname  | 
>> client_port  | 42918
>> backend_start| 2015-06-16 20:31:50.177957+02
>> xact_start   | 
>> query_start  | 2015-06-22 16:25:57.494463+02
>> state_change | 2015-06-22 16:25:57.494564+02
>> waiting  | f
>> state| idle
>> backend_xid  | 
>> backend_xmin | 
>> query| rollback transaction;
>>
>> Ref : 
>> http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-APPLICATION-NAME
>>  
>> http://www.postgresql.org/docs/9.4/static/libpq-connect.html#LIBPQ-CONNSTRING
>>
>>
>> The welll known python driver for postgresql *psycopg2* permots to use 
>> this functionnnality by using kwargs when openning connection as :
>>
>> conn = connect(database='foo', port='5435',
>>host='127.0.0.1', user='rodo',password='rodo',
>>application_name='foobar')
>> le code ici
>>
>> Ref : http://initd.org/psycopg/docs/module.html
>>
>> But, actually Django doesn't permit to use this option, before proposing 
>> a patch to implement this in future version of Django I would like to 
>> receive your comments and idea about this feature.
>> My first idea is to add an optionnal entry in settings.DATABASE as is :
>>
>> DATABASES 
>>  
>> This new key in DATABASE dict will not use by all backends, not only 
>> PostgreSQL has this functionnality, AFAIK SQL Server permits this too.
>>
>> I'll read your comments with interest, this will be my first patch to 
>> Django and I'll be happy to discuss things like what is an acceptable name 
>> for this new entry ?
>> And of course I'll read the Contritbuting to Django before make my PR.
>>
>> Is this feature is accepted, the next step will be to automatically set 
>> this settiings when using the **shell**, **dbshell** or **shell_plus** 
>> command to help identify human action on production systems !
>>
>> Regards,
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0ae0c9e9-022e-4ace-8607-8a28e6bdc30f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Michael Manfre]

+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 releases.
>
> The upside is that the new policy applies right away and we avoid the
> oddball 2.0 and 2.1 releases.
>
> It's much less invasive than the previous idea of renaming 1.9 to 2.0, but
> it still requires renaming PendingDeprecationWarnings in 1.8, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1
> LTS oddball.
> >
> > Regards,
> > Michael Manfre
> >
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson 
> wrote:
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1,
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we
> sacrifice a little bit of strict semver, but it give some nice meaning to
> the version numbers.
> >
> >
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> > Thanks Loïc,
> >
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote:
> > > I've attempted to summarize the history of this thread. Note that I
> > > marked as +1 any generally positive feedback towards a given
> > > proposal, please correct if you feel misrepresented.
> > >
> > [snip]
> > >
> > > # Third iteration:
> > >
> > > 5/ Switching to Semantic Versioning
> > >
> > > Donald mentioned SemVer on IRC a few days ago. Since then various
> > > proposal were made to reconcile it with our release policy. So far
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to
> > > various proposals in that direction but I don't think we have yet
> > > reached consensus on a specific one. Tim updated the Google doc to
> > > reflect my latest proposal, so including me that's 2 formal +1 for
> > > it, but I'd say we should wait for at least a couple more votes
> > > before taking it to the technical board.
> > >
> > > Refs: - http://semver.org/ - Carl's analysis
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J
> > >
> > >
> > - Ryan's proposals
> >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ
> > > - Loïc's proposal
> > >
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ
> >
> > FWIW, I am also +1 on your proposal, as currently documented in the
> > Google doc.
> >
> > I was trying to come up with a proposal where LTS == major release for
> > the sake of argument, since it seemed like that was intuitive to at
> > least some people, but it's not worth the required lengthening of
> > deprecation paths. Your proposal is much better. (And it does make some
> > intuitive sense for the _last_ minor release in a major series to be LTS
> > rather than the first).
> >
> > Carl
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com.
> > To post to this group, send email to django-d...@googlegroups.com.
> > 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > GPG Fingerprint: 74DE D158 BAD0 EDF8
> > keybase.io/manfre
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com
> .
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers  (Contributions to Django itself)" 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.
>

Re: 1.9 release planning

[Tim Graham]

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 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 much less invasive than the previous idea of renaming 1.9 to 2.0, but 
> it still requires renaming PendingDeprecationWarnings in 1.8, and both 
> warnings in 1.9. 
>
> What do you think? 
>
> -- 
> Loïc 
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton  > wrote: 
> > 
> > I'm also +1 on the proposal as it stands, and neutral on when the semver 
> versioning should begin. 
> > 
> > On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote: 
> > I'm +1 on the Google doc proposal and like Markus, I support relabeling 
> 1.9 to 2.0 to line the versions up with the new paradigm without the X.1 
> LTS oddball. 
> > 
> > Regards, 
> > Michael Manfre 
> > 
> > On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  
> wrote: 
> > I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 
> 3.2 LTS, 4.0, etc.) LTS is the final of a major version number, and we 
> sacrifice a little bit of strict semver, but it give some nice meaning to 
> the version numbers. 
> > 
> > 
> > On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote: 
> > Thanks Loïc, 
> > 
> > On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > > I've attempted to summarize the history of this thread. Note that I 
> > > marked as +1 any generally positive feedback towards a given 
> > > proposal, please correct if you feel misrepresented. 
> > > 
> > [snip] 
> > > 
> > > # Third iteration: 
> > > 
> > > 5/ Switching to Semantic Versioning 
> > > 
> > > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > > proposal were made to reconcile it with our release policy. So far 
> > > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > > various proposals in that direction but I don't think we have yet 
> > > reached consensus on a specific one. Tim updated the Google doc to 
> > > reflect my latest proposal, so including me that's 2 formal +1 for 
> > > it, but I'd say we should wait for at least a couple more votes 
> > > before taking it to the technical board. 
> > > 
> > > Refs: - http://semver.org/ - Carl's analysis 
> > > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > > 
> > > 
> > - Ryan's proposals 
> > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > > - Loïc's proposal 
> > > 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> > 
> > FWIW, I am also +1 on your proposal, as currently documented in the 
> > Google doc. 
> > 
> > I was trying to come up with a proposal where LTS == major release for 
> > the sake of argument, since it seemed like that was intuitive to at 
> > least some people, but it's not worth the required lengthening of 
> > deprecation paths. Your proposal is much better. (And it does make some 
> > intuitive sense for the _last_ minor release in a major series to be LTS 
> > rather than the first). 
> > 
> > Carl 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com. 
> > To post to this group, send email to django-d...@googlegroups.com. 
> > 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
> > 
> > -- 
> > GPG Fingerprint: 74DE D158 BAD0 EDF8 
> > keybase.io/manfre 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups "Django developers (Contributions to Django itself)" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to django-develop...@googlegroups.com . 
> > To post to this group, send email to django-d...@googlegroups.com 
> . 
> > 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/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com.
>  
>
> > For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself

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

[Andriy Sokolovskiy (coldmind)]

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 июня 2015 г., 17:56:16 UTC+3 пользователь 
rodolphe.q...@people-doc.com написал:
>
> 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 human tools like 
> *psql* or automated tools like *slony*, this optionnal parameter is 
> called *application_name*. This is very useful to debugging purpose, 
> postgresql prints this information in logs or internal view liek 
> pg_stat_activity, for example
>
> gatling=# select * from pg_stat_activity  limit 1 ;
> -[ RECORD 1 ]+--
> datid| 318636
> datname  | lolyx
> pid  | 8436
> usesysid | 16384
> usename  | rodo
> application_name | slon.local_listen
> client_addr  | ::1
> client_hostname  | 
> client_port  | 42918
> backend_start| 2015-06-16 20:31:50.177957+02
> xact_start   | 
> query_start  | 2015-06-22 16:25:57.494463+02
> state_change | 2015-06-22 16:25:57.494564+02
> waiting  | f
> state| idle
> backend_xid  | 
> backend_xmin | 
> query| rollback transaction;
>
> Ref : 
> http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-APPLICATION-NAME
>  
> http://www.postgresql.org/docs/9.4/static/libpq-connect.html#LIBPQ-CONNSTRING
>
>
> The welll known python driver for postgresql *psycopg2* permots to use 
> this functionnnality by using kwargs when openning connection as :
>
> conn = connect(database='foo', port='5435',
>host='127.0.0.1', user='rodo',password='rodo',
>application_name='foobar')
> le code ici
>
> Ref : http://initd.org/psycopg/docs/module.html
>
> But, actually Django doesn't permit to use this option, before proposing a 
> patch to implement this in future version of Django I would like to receive 
> your comments and idea about this feature.
> My first idea is to add an optionnal entry in settings.DATABASE as is :
>
> DATABASES 
>  
> This new key in DATABASE dict will not use by all backends, not only 
> PostgreSQL has this functionnality, AFAIK SQL Server permits this too.
>
> I'll read your comments with interest, this will be my first patch to 
> Django and I'll be happy to discuss things like what is an acceptable name 
> for this new entry ?
> And of course I'll read the Contritbuting to Django before make my PR.
>
> Is this feature is accepted, the next step will be to automatically set 
> this settiings when using the **shell**, **dbshell** or **shell_plus** 
> command to help identify human action on production systems !
>
> Regards,
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/002774b4-5e73-4ea1-a15d-b838650f840d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proposal for a new key in settings.DATABASE dict

[rodolphe . quiedeville]

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 human tools like *psql* 
or automated tools like *slony*, this optionnal parameter is called 
*application_name*. This is very useful to debugging purpose, postgresql 
prints this information in logs or internal view liek pg_stat_activity, for 
example

gatling=# select * from pg_stat_activity  limit 1 ;
-[ RECORD 1 ]+--
datid| 318636
datname  | lolyx
pid  | 8436
usesysid | 16384
usename  | rodo
application_name | slon.local_listen
client_addr  | ::1
client_hostname  | 
client_port  | 42918
backend_start| 2015-06-16 20:31:50.177957+02
xact_start   | 
query_start  | 2015-06-22 16:25:57.494463+02
state_change | 2015-06-22 16:25:57.494564+02
waiting  | f
state| idle
backend_xid  | 
backend_xmin | 
query| rollback transaction;

Ref : 
http://www.postgresql.org/docs/current/static/runtime-config-logging.html#GUC-APPLICATION-NAME
 http://www.postgresql.org/docs/9.4/static/libpq-connect.html#LIBPQ-CONNSTRING


The welll known python driver for postgresql *psycopg2* permots to use this 
functionnnality by using kwargs when openning connection as :

conn = connect(database='foo', port='5435',
   host='127.0.0.1', user='rodo',password='rodo',
   application_name='foobar')
le code ici

Ref : http://initd.org/psycopg/docs/module.html

But, actually Django doesn't permit to use this option, before proposing a 
patch to implement this in future version of Django I would like to receive 
your comments and idea about this feature.
My first idea is to add an optionnal entry in settings.DATABASE as is :

DATABASES 
 
This new key in DATABASE dict will not use by all backends, not only 
PostgreSQL has this functionnality, AFAIK SQL Server permits this too.

I'll read your comments with interest, this will be my first patch to 
Django and I'll be happy to discuss things like what is an acceptable name 
for this new entry ?
And of course I'll read the Contritbuting to Django before make my PR.

Is this feature is accepted, the next step will be to automatically set 
this settiings when using the **shell**, **dbshell** or **shell_plus** 
command to help identify human action on production systems !

Regards,

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/97cb7ff5-0b4d-4c33-9545-1a8577678ccd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Loïc Bistuer]

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 much less invasive than the previous idea of renaming 1.9 to 2.0, but it 
still requires renaming PendingDeprecationWarnings in 1.8, and both warnings in 
1.9.

What do you think?

-- 
Loïc

> On Jun 17, 2015, at 08:47, Josh Smeaton  wrote:
> 
> I'm also +1 on the proposal as it stands, and neutral on when the semver 
> versioning should begin.
> 
> On Wednesday, 17 June 2015 05:03:47 UTC+10, Michael Manfre wrote:
> I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9 
> to 2.0 to line the versions up with the new paradigm without the X.1 LTS 
> oddball.
> 
> Regards,
> Michael Manfre
> 
> On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson  wrote:
> I also like the gdoc as it is. (1.8 LTS, 1.9, 2.0, 2.1 LTS, 3.0, 3.1, 3.2 
> LTS, 4.0, etc.) LTS is the final of a major version number, and we sacrifice 
> a little bit of strict semver, but it give some nice meaning to the version 
> numbers.
> 
> 
> On Tuesday, June 16, 2015 at 12:22:44 PM UTC-4, Carl Meyer wrote:
> Thanks Loïc, 
> 
> On 06/16/2015 01:15 AM, Loïc Bistuer wrote: 
> > I've attempted to summarize the history of this thread. Note that I 
> > marked as +1 any generally positive feedback towards a given 
> > proposal, please correct if you feel misrepresented. 
> > 
> [snip] 
> > 
> > # Third iteration: 
> > 
> > 5/ Switching to Semantic Versioning 
> > 
> > Donald mentioned SemVer on IRC a few days ago. Since then various 
> > proposal were made to reconcile it with our release policy. So far 
> > Collin, Carl, Loïc, Tim, and Josh have expressed positive feedback to 
> > various proposals in that direction but I don't think we have yet 
> > reached consensus on a specific one. Tim updated the Google doc to 
> > reflect my latest proposal, so including me that's 2 formal +1 for 
> > it, but I'd say we should wait for at least a couple more votes 
> > before taking it to the technical board. 
> > 
> > Refs: - http://semver.org/ - Carl's analysis 
> > https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/Ojov2QBROg8J 
> > 
> > 
> - Ryan's proposals 
> https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/lBLWrhKJ6DIJ 
> > - Loïc's proposal 
> > https://groups.google.com/d/msg/django-developers/MTvOPDNQXLI/y2QbPVzSs6cJ 
> 
> FWIW, I am also +1 on your proposal, as currently documented in the 
> Google doc. 
> 
> I was trying to come up with a proposal where LTS == major release for 
> the sake of argument, since it seemed like that was intuitive to at 
> least some people, but it's not worth the required lengthening of 
> deprecation paths. Your proposal is much better. (And it does make some 
> intuitive sense for the _last_ minor release in a major series to be LTS 
> rather than the first). 
> 
> Carl 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> 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/ebc7b0ae-27aa-4848-a6b5-9cec4b374895%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> GPG Fingerprint: 74DE D158 BAD0 EDF8
> keybase.io/manfre
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/79aae5a5-58dd-4f05-a6dd-35685e06ebb5%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/857E068D-347C-4C6A-8A1F-41569C3BC476%40gmail.com.
For more options, visit https://gr

Re: Django Admin - list_display default value

[Rick van Hattem (wolph)]

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.

On Monday 15 June 2015 22:52:09 Rick van Hattem wrote: 
> > On 15 June 2015 at 21:34, Florian Apolloner  > wrote: 
> > > On Monday, June 15, 2015 at 7:07:38 PM UTC+2, Rick van Hattem (wolph) 
> > > 
> > > wrote: 
> > >> Would anyone oppose a pull request like this? 
> > > 
> > > Yes, it is highly backwards incompatible for not much gain, I am also 
> > > usually just fine with one/two fields for list_display. You could just 
> > > use your own admin subclass for that. 
> > 
> > Can you clarify on that? I don't see the backwards incompatibility here. 
> > 
>
> It could quite easily cause breakage for specific client-side code, 
> although I 
> wouldn't consider that "highly" incompatible. 
>
> However, it could also easily lead to inappropriate data exposure -- where 
> people who are supposed to get an "opaque" view of some objects will, upon 
> upgrade, be able to see all their details. I consider that risk to weigh 
> much 
> more than the potential gains. 
>

Ah, yes... you are right, I didn't take that into consideration. That is a 
very valid argument, you have persuaded me that it shouldn't change the 
behaviour in all cases.

 

> > 
> > The discussion here shouldn't be whether you can or cannot fix it 
> yourself 
> > (obviously, you can, that's not the issue), it's what a good/sane 
> default 
> > would be. For brand new Django users, would it be more convenient to 
> have 1 
> > column or just all local columns and make it slightly more usable? 
> > 
> Beside "convenient", you should also consider "safe", and besides brand 
> new 
> users, there are also established users with significant codebases. Now, 
> arguably, if we were starting the Django project today, we could use the 
> default you propose, people would be aware of it, and if they wanted to 
> limit 
> access, they would. One could still argue that "whitelisting" is better 
> than 
> "blacklisting", and we could have a whole discussion about this. But 
> having a 
> Django upgrade just expose more data by default, even in the Admin, would 
> be a 
> serious breach of our users' trust IMO. 
>

Generally I'm a great proponent of whitelisting versus blacklisting, with 
the admin, I'm not because by default all of the fields are already visible 
when editing. So right now it's just inconsistent between the two.

Although I'm not a fan of magic, if the fields and/or fieldset are not set 
within the admin, they're already visible so in that case it might still be 
a good default. Conditional defaults are less than optimal of course... 
what are your thoughts about a solution like that?

Or as Marc suggests, supporting __all__ would help a lot too.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/edd1cfeb-04ec-4fe4-a2c1-d6d26fb4261b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.