Re: Logging config tries too hard

[Tim Graham]

Carl, I think this is the thread with your past comments: 
https://groups.google.com/d/topic/django-developers/no2IhnRty68/discussion

To avoid a new setting, we could add some custom key/value to LOGGING for 
the new behavior and pop it before the dict is passed to dictConfig.

On Tuesday, September 6, 2016 at 8:44:37 PM UTC-4, Carl Meyer wrote:
>
> On 09/06/2016 04:57 PM, Ivan Sagalaev wrote: 
> > I'm 
> > talking about this function: 
> > https://github.com/django/django/blob/master/django/utils/log.py#L66 
> > 
> > When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally 
> > initializes logging with the hard-coded configuration and then applies a 
> > user one, if present. And the latter can't really neutralize the effect 
> > of the former. 
>
> FWIW I agree that the current behavior here is broken and should be 
> fixed. The design seems to be based in an assumption that 
> `disable_existing_loggers=True` can "undo" the effects of the previous 
> config, when it can't, and in fact it does something much nastier -- it 
> silences all previously-created loggers. 
>
> I clearly recall outlining this issue in a Trac ticket at some point 
> quite a while ago, but I can't seem to find that ticket now. 
>
> Fixing this in a way that doesn't change logging behavior for projects 
> upgrading from a previous Django version may be tricky, unless we gate 
> the effect of the change on (yet another) setting. 
>
> 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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2f542c9c-3ff5-43db-acba-dc3505935645%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Carl Meyer]

On 09/06/2016 04:57 PM, Ivan Sagalaev wrote:
> I'm
> talking about this function:
> https://github.com/django/django/blob/master/django/utils/log.py#L66
> 
> When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally
> initializes logging with the hard-coded configuration and then applies a
> user one, if present. And the latter can't really neutralize the effect
> of the former.

FWIW I agree that the current behavior here is broken and should be
fixed. The design seems to be based in an assumption that
`disable_existing_loggers=True` can "undo" the effects of the previous
config, when it can't, and in fact it does something much nastier -- it
silences all previously-created loggers.

I clearly recall outlining this issue in a Trac ticket at some point
quite a while ago, but I can't seem to find that ticket now.

Fixing this in a way that doesn't change logging behavior for projects
upgrading from a previous Django version may be tricky, unless we gate
the effect of the change on (yet another) setting.

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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/21d52615-35ac-4091-92c9-4ef14fbd4e0f%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Logging config tries too hard

[Ivan Sagalaev]

>
> Just to be sure, which version of Django are you using? There were some 
> simplifications in Django 1.9 that attempted to make writing custom logging 
> configurations easier and further changes in Django 1.10.
>

I'm using 1.9, but I'm referring to the code in master. 
 

>
> https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5
>
> https://github.com/django/django/commit/5b94b17feff15a9f0345f92fc0568bfe7038e3a3
>

I don't see how these have anything to do with what I'm describing. I'm 
talking about this function: 
https://github.com/django/django/blob/master/django/utils/log.py#L66

When `LOGGING_CONFIG` isn't explicitly disabled it first unconditionally 
initializes logging with the hard-coded configuration and then applies a 
user one, if present. And the latter can't really neutralize the effect of 
the former.

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6878a75-1e12-4430-86e8-4c5d71ca0972%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Ivan Sagalaev]

>
> It’s unclear to me as well how the current system is intended to be used.
>

I can speculate, that the idea was that you *can* disable the existing 
loggers and define your own, but the effect of it actually disabling all 
logging from Django instead of it falling through to the custom root logger 
was overlooked. 

All my projects do this:
>
> # Configure logging manually to avoid merging with Django's defaults.
>
> LOGGING = {
> # custom logging configuration goes here
> }
>
> logging.config.dictConfig(LOGGING)
>
> LOGGING_CONFIG = None
>
> Yes, that's the workaround I'm using right now, too. It works, but it's 
not very clean with having to import logging and do this non-obvious dance 
for what feels like it should just be the default behavior. 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a9bf595c-ef52-46df-baee-2c5056c992c1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding support for importing models through the app registry while it is loading

[Carl Meyer]

On 09/06/2016 12:55 PM, Aymeric Augustin wrote:
> Hi Carl,
> 
> Thanks for the feedback!

Of course! Thanks for working on things :-)

> ...
> The change I’m proposing doesn’t introduce random bugs. If models are
> missing reverse relations, that will be deterministic.

+1

>> Is it possible
>> to make it so that even the model meta introspection APIs (and of course
>> also any attempt to query the db) fail quickly, loudly, and with a clear
>> error message if the app registry is not yet fully populated? If so,
>> then I think there's little risk to adding this API (and in fact I think
>> we could even make it the default behavior of `get_model`).
> 
> If not checking for models_ready was the default for get_model(), then I’d
> expect it to be the default for get_models() as well, but that doesn’t make
> sense. get_models() really needs all models to be imported.
> 
> My initial patch added a new method, `import_model`, because the operation is
> quite different from the app registry's perspective. Instead of just looking
> up the model, we try to import it. Even though the end result feels the same,
> the context isn't the same.

Yes, this makes sense. It suggests another possible name for the kwarg,
`force_import=True`?

...
> Without looking at the code base, I can’t say. It might help if you’re doing
> swappable-model-style dynamic imports. It won’t help if you’re importing
> models directly or indirectly from your applications’s __init__.py, which is
> a more common problem.

Yes, I think it's likely this wouldn't help much.

> I think #21719 would have led there as well but it turned out to be
> surprisingly hard -- in the realm of "not sure I'd get anywhere even if I
> spent two weeks full-time on it”.

I still think that's the right approach (and should be possible) in
theory, but I trust your estimation of complexity and am currently short
of two-week-plus blocks of free time :-)

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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7d1c5071-b1c5-6fdb-e12c-7d7ebf3cb852%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Adding support for importing models through the app registry while it is loading

[Aymeric Augustin]

Hi Carl,

Thanks for the feedback!

> On 06 Sep 2016, at 19:39, Carl Meyer  wrote:
> 
> 1) A kwarg to `get_model` seems fine, but I don't like the vague FUD of
> `unsafe=True` (if it's really "not safe" we shouldn't add it / make it
> public at all). How about something more specific like
> `require_ready=False`?

Agreed. Actually I thought there must be a better name but didn’t have a
better idea and then I forgot to mention it, the email was quite long already.

> 2) I think a key question here is the nature and clarity of the problems
> that arise if you try to make use of an un-ready model class. If the
> failure mode here is the reintroduction of unpredictable heisenbugs
> where certain related fields are quietly not present because the model
> on the other end happens to not have been imported yet, I think that's a
> strong argument for refraining from introducing this API.

In Django 1.7+, I’m pretty sure the import sequence is fully deterministic for
a given version of a project.

get_wsgi_application() runs django.setup() first thing. Not user code has been
imported at that point.

django.setup() accesses settings, which can import user code but shouldn’t —
it’s super easy to create import loops if it does. In general settings don't
import much. They might be able to import models but that's pathological.
Just don't do that.

Then apps.populate() imports apps and models in the order of INSTALLED_APPS.
This is fully deterministic, even with multi-threading: the first thread that
reaches populate() takes a lock and other threads wait until that thread has
finished.

At this point all models have been imported according in a fully deterministic
sequence (assuming non-pathological code e.g. `if random() > 0.5: import foo`)

I believe the next step is to import URLs. I didn't check if that happens
immediately or when the first request is received. Some non-determinism might
happen here, especially  with per-request urlconfs, but let's focus on models
and leave that question for another day :-)

The change I’m proposing doesn’t introduce random bugs. If models are
missing reverse relations, that will be deterministic.

> Is it possible
> to make it so that even the model meta introspection APIs (and of course
> also any attempt to query the db) fail quickly, loudly, and with a clear
> error message if the app registry is not yet fully populated? If so,
> then I think there's little risk to adding this API (and in fact I think
> we could even make it the default behavior of `get_model`).

If not checking for models_ready was the default for get_model(), then I’d
expect it to be the default for get_models() as well, but that doesn’t make
sense. get_models() really needs all models to be imported.

My initial patch added a new method, `import_model`, because the operation is
quite different from the app registry's perspective. Instead of just looking
up the model, we try to import it. Even though the end result feels the same,
the context isn't the same.

Also, from the "separation of concerns" angle, I'm not eager to create
coupling between the model meta API and the app registry.

So, while I get the appeal of not adding a somewhat scary kwarg, I still think
it's good to have users declare that they're treading into pre-`models_ready`
territory.

We could relax this constraint later by ignoring the require_ready argument,
at the cost of some code churn in third-party apps that started using it.

> As for whether it's needed in real use, the only feedback I can offer at
> the moment is that the import-order enforcement that kicked in with the
> removal of app-loading deprecation shims in Django 1.9 is the primary
> reason that Instagram has so far upgraded only as far as Django 1.8;

BRB finding a patch of sand to bury my head in...

> fixing the import-order issues appeared to require too much upheaval and
> would have delayed the upgrade too much. I haven't had time to look
> closely at those issues so I can't yet offer more detailed feedback on
> how much the availability of this particular API would help.

Without looking at the code base, I can’t say. It might help if you’re doing
swappable-model-style dynamic imports. It won’t help if you’re importing
models directly or indirectly from your applications’s __init__.py, which is
a more common problem.

For the record this is tracked in #24312 but that ticket neither describes the
exact problem nor possible ways to tackle it.

I think #21719 would have led there as well but it turned out to be
surprisingly hard -- in the realm of "not sure I'd get anywhere even if I
spent two weeks full-time on it”.

-- 
Aymeric.


-- 
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 

Re: Adding support for importing models through the app registry while it is loading

[Carl Meyer]

Hi Aymeric,

On 09/04/2016 01:03 PM, Aymeric Augustin wrote:
> Hello,
> 
> Since Django 1.7, `get_user_model()` cannot be called at import time.
> Django contains a lot of methods that start with `UserModel =
> get_user_model()` while it would be more natural to declare it as a
> global variable in the module. This trips up users and the reason why
> it’s forbidden isn’t obvious.
...
> However, in many cases, it doesn’t matter whether the model is fully
> constructed or not. In the use case I described in my introduction,
> the code only needs a reference to the model class at import time;
> that reference won’t be used until run time, after the app-loading
> process has completed. (Performing SQL queries through the ORM at
> import time doesn’t work anyway.)
> 
> For this reason, I think it would make sense to add an API similar to
> `apps.get_models()`, but that would work while app-loading is still
> in progress. It would make no guarantees about the functionality of
> the class it returns until app-loading has completed.
> 
> I implemented a proof of concept here:
> https://github.com/django/django/pull/6547.

A few thoughts:

1) A kwarg to `get_model` seems fine, but I don't like the vague FUD of
`unsafe=True` (if it's really "not safe" we shouldn't add it / make it
public at all). How about something more specific like
`require_ready=False`?

2) I think a key question here is the nature and clarity of the problems
that arise if you try to make use of an un-ready model class. If the
failure mode here is the reintroduction of unpredictable heisenbugs
where certain related fields are quietly not present because the model
on the other end happens to not have been imported yet, I think that's a
strong argument for refraining from introducing this API. Is it possible
to make it so that even the model meta introspection APIs (and of course
also any attempt to query the db) fail quickly, loudly, and with a clear
error message if the app registry is not yet fully populated? If so,
then I think there's little risk to adding this API (and in fact I think
we could even make it the default behavior of `get_model`).

As for whether it's needed in real use, the only feedback I can offer at
the moment is that the import-order enforcement that kicked in with the
removal of app-loading deprecation shims in Django 1.9 is the primary
reason that Instagram has so far upgraded only as far as Django 1.8;
fixing the import-order issues appeared to require too much upheaval and
would have delayed the upgrade too much. I haven't had time to look
closely at those issues so I can't yet offer more detailed feedback on
how much the availability of this particular API would help.

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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eabf51d0-712e-32f1-d8e4-320ddf7681ad%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Logging config tries too hard

[Tim Graham]

Just to be sure, which version of Django are you using? There were some 
simplifications in Django 1.9 that attempted to make writing custom logging 
configurations easier and further changes in Django 1.10.

https://github.com/django/django/commit/8efea1b8d5b5fb0cfef1a3244c339cebf8af36c5
https://github.com/django/django/commit/5b94b17feff15a9f0345f92fc0568bfe7038e3a3

On Tuesday, September 6, 2016 at 8:57:16 AM UTC-4, Ivan Sagalaev wrote:
>
> Hello everyone,
>
> It's been a while since I last posted here, please forgive if I break any 
> new rules inadvertently.
>
> I'd like to revisit a decision made in [18993][]. My use case is very 
> simple and obvious: I want all logging going into stdout.
>
> As currently implemented, I can't do it easily with a custom `LOGGING` 
> setting, because:
>
> - If I leave existing Django loggers enabled it ties me to the behavior 
> chosen by Django, which doesn't necessarily match what I want. For example, 
> Django won't log debug and info messages if `DEBUG = False`. And with 
> `DEBUG = True` I will be having two log messages for every log into the 
> 'django' logger: one from the Django's own handler, and another after it 
> propagates to my root logger.
>
> - If I disable existing Django loggers, I effectively disable all logging 
> from Django (and from 'py.warnings' for good measure).
>
> In fact, the idea of providing a default logging configuration which a 
> user can then *build upon* isn't really workable with Python logging: you 
> can either fully reuse or fully discard what's been provided, but you can't 
> meaningfully define a consistent configuration. Also, I have my doubts that 
> this "build upon" use case is based on any real demand. In my experience 
> there are only two approaches to configuring logging: "logging? huh, didn't 
> think about it" and "get your hands off my logging, I know what I'm doing!"
>
> The latter, incidentally, is what the old way was doing: define a sensible 
> default value for `LOGGING` and let users to overwrite it completely. 
> Currently, the default logging configuration is hard-coded in 
> `django.utils.log`.
>
> Also, I couldn't find the actual reasoning for the current behavior in the 
> original ticket. It starts talking about having a more useful default, not 
> about changing the way how this default configuration is applied.
>
> [18993]: https://code.djangoproject.com/ticket/18993
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f8538ee9-3e0b-414a-b467-ff083c410b7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Logging config tries too hard

[Aymeric Augustin]

It’s unclear to me as well how the current system is intended to be used.

All my projects do this:

> # Configure logging manually to avoid merging with Django's defaults.
> 
> LOGGING = {
> # custom logging configuration goes here
> }
> 
> logging.config.dictConfig(LOGGING)
> 
> LOGGING_CONFIG = None

Essentially they enforce my logging config and prevent Django from interfering.

I’ve never managed to get results I understand with any other technique.

Likely I could figure it out, given enough time, but until now I haven’t.

-- 
Aymeric.


> On 06 Sep 2016, at 07:52, Ivan Sagalaev  wrote:
> 
> Hello everyone,
> 
> It's been a while since I last posted here, please forgive if I break any new 
> rules inadvertently.
> 
> I'd like to revisit a decision made in [18993][]. My use case is very simple 
> and obvious: I want all logging going into stdout.
> 
> As currently implemented, I can't do it easily with a custom `LOGGING` 
> setting, because:
> 
> - If I leave existing Django loggers enabled it ties me to the behavior 
> chosen by Django, which doesn't necessarily match what I want. For example, 
> Django won't log debug and info messages if `DEBUG = False`. And with `DEBUG 
> = True` I will be having two log messages for every log into the 'django' 
> logger: one from the Django's own handler, and another after it propagates to 
> my root logger.
> 
> - If I disable existing Django loggers, I effectively disable all logging 
> from Django (and from 'py.warnings' for good measure).
> 
> In fact, the idea of providing a default logging configuration which a user 
> can then *build upon* isn't really workable with Python logging: you can 
> either fully reuse or fully discard what's been provided, but you can't 
> meaningfully define a consistent configuration. Also, I have my doubts that 
> this "build upon" use case is based on any real demand. In my experience 
> there are only two approaches to configuring logging: "logging? huh, didn't 
> think about it" and "get your hands off my logging, I know what I'm doing!"
> 
> The latter, incidentally, is what the old way was doing: define a sensible 
> default value for `LOGGING` and let users to overwrite it completely. 
> Currently, the default logging configuration is hard-coded in 
> `django.utils.log`.
> 
> Also, I couldn't find the actual reasoning for the current behavior in the 
> original ticket. It starts talking about having a more useful default, not 
> about changing the way how this default configuration is applied.
> 
> [18993]: https://code.djangoproject.com/ticket/18993
> 
> -- 
> 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 https://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/57ca68fd-214a-4fe4-b759-7fc8cb597b35%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A856D036-644D-4485-ADE8-9AE2629ACD22%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Logging config tries too hard

[Ivan Sagalaev]

Hello everyone,

It's been a while since I last posted here, please forgive if I break any 
new rules inadvertently.

I'd like to revisit a decision made in [18993][]. My use case is very 
simple and obvious: I want all logging going into stdout.

As currently implemented, I can't do it easily with a custom `LOGGING` 
setting, because:

- If I leave existing Django loggers enabled it ties me to the behavior 
chosen by Django, which doesn't necessarily match what I want. For example, 
Django won't log debug and info messages if `DEBUG = False`. And with 
`DEBUG = True` I will be having two log messages for every log into the 
'django' logger: one from the Django's own handler, and another after it 
propagates to my root logger.

- If I disable existing Django loggers, I effectively disable all logging 
from Django (and from 'py.warnings' for good measure).

In fact, the idea of providing a default logging configuration which a user 
can then *build upon* isn't really workable with Python logging: you can 
either fully reuse or fully discard what's been provided, but you can't 
meaningfully define a consistent configuration. Also, I have my doubts that 
this "build upon" use case is based on any real demand. In my experience 
there are only two approaches to configuring logging: "logging? huh, didn't 
think about it" and "get your hands off my logging, I know what I'm doing!"

The latter, incidentally, is what the old way was doing: define a sensible 
default value for `LOGGING` and let users to overwrite it completely. 
Currently, the default logging configuration is hard-coded in 
`django.utils.log`.

Also, I couldn't find the actual reasoning for the current behavior in the 
original ticket. It starts talking about having a more useful default, not 
about changing the way how this default configuration is applied.

[18993]: https://code.djangoproject.com/ticket/18993

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57ca68fd-214a-4fe4-b759-7fc8cb597b35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sonar for the Django rpoject

[Ivan Sevastoyanov]

Hello,

I'm back from the vacation.

@Hanne Moa - As far as I know, you can skip packages, files and everything 
can be customized. It's the same with the rules. I did not prioritized the 
Sonar rules - they are the default ones and Sonar is detecting not only 
possible bugs and issues but code smells, some ideas for improving the 
readability and maintainability, etc. So I agree that these "criticals" 
are, in fact, not real "criticals" - they are not issues, they will not 
improve the performance, they are just a tip to improve the readability of 
the code. But you have the full power to customize the rules and choose 
which of them are blockers, criticals, major, minor and info.

@Aymeric Augustin - Yes, it's easy to reproduce the results. Unfortunately, 
I installed the latest version of Sonar and some of the plug-ins for 
exporting into PDF and HTML are still not compatible. I can install some 
older version and put an old working plug-in into work. But I'm not sure if 
the rules will be the same or less than now. I will review the rules and 
will send an e-mail if I think some of them are security issues. Other I 
can do is to write a blog post how to install SonarQube and some of the 
plug-ins and how to configure them but I don't know when I will have enough 
time for doing that.

@Alex Gaynor - You can see what I wrote to Hanne Moa.

@James Bennett - You can see what I wrote to Hanne Moa. The rules should be 
prioritized but in my honest opinion I'm not the right person for doing 
that. I can copy/paste the rules here but I'm not sure that some of them 
are understandable from their short description.

Regards,
Ivan

On Monday, September 5, 2016 at 5:40:41 PM UTC+3, James Bennett wrote:
>
> On Wed, Aug 31, 2016 at 10:55 AM, Alex Gaynor  > wrote:
>
>> If these are what qualifies as critical, I don't think this is a good use 
>> of our time.
>>
>>
>>
> Agreed. If those are the critical things, then either Django is really 
> really good, or there are things it's missing. I suspect there are things 
> it's missing. 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/85278cfb-8468-41c2-9b6b-16dd59b6f38e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Creating page types programatically

[Iacopo Spalletti]

Il 06/09/2016 13:41, Patrick Heneghan ha scritto:
> Posted already to the Github issue tracker, but it was suggested I post
> here instead:
> 
> 
> In other CMS's I've used, it's been possible to define Page Types (or
> "post types") programatically. This is desirable, as it allows me to
> commit these to code, and have them ready for use when the site has been
> installed - rather than going through the manual process of creating
> them via the admin area post-installation.
> 
> 
> Is this possible in Django CMS? It doesn't seem to be documented.

Do you mean "Page Type" in the django CMS meaning (ie: special pages
prefilled with content) or just page templates? In the latter django
templates configured in CMS_TEMPLATES are what you are looking for.

In the former case django CMS Page types are just pages saved under a
special parent.
If you want to ship them together with the code you have two options:
- saving a fixture file with the pre-saved pages
- create a datamigration which creates the pages using create_page /
create_title / add_plugin public API
(http://django-cms.readthedocs.io/en/release-3.3.x/reference/api.html)

Hope this helps

> 
> -- 
> Message URL: *MailScanner has detected definite fraud in the website at
> "groups.google.com". Do /not/ trust this website:*
> https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id 
> 
> Unsubscribe: send a message to
> django-cms-developers+unsubscr...@googlegroups.com
> ---
> You received this message because you are subscribed to the Google
> Groups "django CMS developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-cms-developers+unsubscr...@googlegroups.com
> .
> To view this discussion on the web, visit *MailScanner has detected
> definite fraud in the website at "groups.google.com". Do /not/ trust
> this website:*
> https://groups.google.com/d/msgid/django-cms-developers/04effbc0-fe73-4fc8-a17a-325ab82d701f%40googlegroups.com
> .
> For more options, visit *MailScanner has detected definite fraud in the
> website at "groups.google.com". Do /not/ trust this website:*
> https://groups.google.com/d/optout .


-- 
Iacopo Spalletti

Nephila s.a.s. - Firenze
Telefono: +39 055 5357189
Assistenza Tecnica: +39 055 3985730
http://nephi.la

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/f9f253e2-6d6e-7c5c-e8e1-5ecc5dc34294%40nephila.it.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature