Re: @load_fixture annotation for test cases.

2014-09-02 Thread Josh Smeaton 
The idea isn't bad, except that the performance of fixture loading is 
pretty terrible in general. Take a look at 
ticket https://code.djangoproject.com/ticket/20392 for some performance 
profiling and discussion.

As far as I'm concerned, using fixtures is the wrong way to populate data 
for tests. You're much better off creating the objects you need for each 
test within the test, or creating them directly inside the setUp method. 
You avoid the parsing and loading of json data, which is quite substantial!

You could also use a third party app like factory boy to generate the data 
you need for each test. I think we should be encouraging this kind of 
design a lot more, rather than trying to optimise or push fixture loading 
in general.

Regards,

Josh

On Wednesday, 3 September 2014 04:34:17 UTC+10, Matteo Kloiber wrote:
>
> Hello,
> I thought it might be pretty helpful if there was a load_fixtures 
> annotation that loads fixture for a specific test method 
> in TransactionTestCase. On some occasions, it might be pretty hard to test 
> a model/view that uses only one or a few fixtures that are always the same. 
> Here are some occasions, where it might be helpful to have these 
> annotation. 
>
>  - I may want to test when the database is empty.
>  - It might be necessary to have a fixture with a lot of data (and I mean 
> >1000). Loading some much data for every testcase is highly ineffective 
> because it takes a time to clean up and load the data again.
>
> I’m sure there are more occasions when this might be helpful.
> Here is what the implementation might look like:
>
> @load_fixtures(*fixtures, flush=False)
>
> fixtures are the fixtures to load (just like the instance variable). flush 
> means whether the old data (i.e. the data that was loaded by the instance 
> variable) should be flushed. `fixtures` should be optional so that flush 
> can sand-alone. That allows me to have an empty database (this could be 
> useful when only a very limited amount of tests need an empty database 
> while the other tests need the default fixtures). 
> It shouldn’t replace the fixtures instance variable, it should just be an 
> addition. 
>
> I know, it can be implemented and doesn’t require changes in the core but 
> it would be super helpful if it came out if the box. The flush parameter 
> could be optimized when implementing directly in the core 
> (i.e. TransactionTestCase). Loading default fixtures (the ones defined in 
> TestCase.fixture) could be prevented this way and the tests might even run 
> a bit quicker. This is quicker than flushing the database/rolling back all 
> changes.
>
> Sincerely,
> Matteo Kloiber
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/65066a0f-92cb-4639-88ad-c18f1b6532a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.7 released

2014-09-02 Thread Bruno Ribeiro da Silva 
That's good news!
On Sep 2, 2014 7:13 PM, "James Bennett"  wrote:

> Django 1.7 is now available:
>
> https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/
>
> Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5
> release is the final releae in the 1.5 series, as Django 1.5 has now
> reached end-of-life.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.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" 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/CAE-2%3DJw%3D_ZN0RzJEgo-eC5RxMAK%3DEE-0FpqPGgf-fm9%2BYG6v1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.7 released

2014-09-02 Thread Andrey Antukh 
Awesome! Thanks!


2014-09-03 0:15 GMT+02:00 Carlos Aguilar :

> congratulations!!!
>
> And thank you for a really good job!
>
> Best Regards
>
>
> On Tue, Sep 2, 2014 at 4:13 PM, James Bennett 
> wrote:
>
>> Django 1.7 is now available:
>>
>> https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/
>>
>> Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5
>> release is the final releae in the 1.5 series, as Django 1.5 has now
>> reached end-of-life.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Carlos Aguilar
> Consultor Hardware y Software
> DWD
> http://www.dwdandsolutions.com
> http://www.houseofsysadmin.com
> Cel: +50378735118
> USA: (301) 337-8541
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAN-g%3Dg%3DW_9MXJiFawGX%2BczkVXLRKhdb6Zvp3AQU6sjnf2zPy7g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrey Antukh - Андрей Антух -  / 
http://www.niwi.be 
https://github.com/niwibe

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAKn%3DmOMrosWn7EOiyQJMD4%2Bph6jO681dT%3DKb-S-4MT5p2sBeAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANNOUNCE] Django 1.7 released

2014-09-02 Thread Carlos Aguilar 
congratulations!!!

And thank you for a really good job!

Best Regards


On Tue, Sep 2, 2014 at 4:13 PM, James Bennett  wrote:

> Django 1.7 is now available:
>
> https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/
>
> Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5
> release is the final releae in the 1.5 series, as Django 1.5 has now
> reached end-of-life.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Carlos Aguilar
Consultor Hardware y Software
DWD
http://www.dwdandsolutions.com
http://www.houseofsysadmin.com
Cel: +50378735118
USA: (301) 337-8541

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAN-g%3Dg%3DW_9MXJiFawGX%2BczkVXLRKhdb6Zvp3AQU6sjnf2zPy7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ANNOUNCE] Django 1.7 released

2014-09-02 Thread James Bennett 
Django 1.7 is now available:

https://www.djangoproject.com/weblog/2014/sep/02/release-17-final/

Alongside this are bugfix releases for 1.4, 1.5 and 1.6. The bugfix 1.5
release is the final releae in the 1.5 series, as Django 1.5 has now
reached end-of-life.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAL13Cg_Cdzf3aYLxfV0qgrMY3CqbOqt%3D0DxEm1V27%2BzF65O_cA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] django-synth, a bridge to Synth's C++ template engines

2014-09-02 Thread Michael Buckley 
On Sunday, August 31, 2014 10:43:48 PM UTC+2, Aymeric Augustin wrote:
>
> If you look at the first email in this thread, you’ll see that 
> django_synth provides its own template loader. 
>
> Sure it does, but does that mean I can do this?

TEMPLATE_LOADERS = (
('django.template.loaders.cached.Loader', (
'django_synth.loaders.FilesystemLoader',
'django_synth.loaders.AppDirectoriesLoader',
)),
)

Or is that not needed?  I am guessing from your answer that it is not.

Also is the 10 - 30x faster, done against the speed of the 
django.template.loaders.cached.Loader or the default  filesystem.Loader and 
app_directories.Loader?  It makes a large differences. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/d78bb54a-75d5-495c-ba06-7e359f263d74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

2014-09-02 Thread Carl Meyer 
On 09/01/2014 02:34 PM, Michael Manfre wrote:
> On Mon, Sep 1, 2014 at 2:12 PM, Aymeric Augustin
>  > wrote:
> 
> If we recommend HSTS, we need visible warnings and a small duration
> in examples, for people who copy-paste without reading.
> 
> 
> The default duration should also be less than a day for the exact reason
> brought up. The visible warnings could state why it is a good idea to
> increase the duration, after it is tested in production.

There is no default duration; the default is no HSTS at all. Tim has
updated the documentation to warn about the possible issues, and
recommend testing with a short duration before increasing.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/540615E7.9060408%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: integrating django-secure

2014-09-02 Thread Carl Meyer 
On 09/01/2014 11:31 AM, Erik Romijn wrote:
[snip]
> So, although I encourage anyone to enable HSTS, we should not recommend
> people to just "switch it on". They should be well aware of the
> consequences as it can affect an unknown set of users beyond their
> Django site, long after the change has been reverted. The possible
> seriousness should be reflected in any encouragement we make for HSTS to
> be enabled.

I very much agree with this concern. I think Tim has already added good
warnings to the documentation for HSTS; in comments on the pull request
I'm also advocating for adding at least a brief note to the warning
message itself, along the lines of "you can break things badly if you
enable this without reading the documentation first."

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/540614C3.6040206%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

2014-09-02 Thread shmengie 
Pkl, 

You shouldn't have to upgrade all your old sites to the latest version of 
Django, unless you want maintain current methods. 

This is why we like virtual environments, much.

The core team has made a nice set of security releases available via pip.  
Django 1.4.14, Django 1.5.9, Django 1.6.6, and Django 1.7

# See package version in your environment
$\> pip freeze

# This command should get fetch security updates w/out breaking eco-system.
$\> pip install Django --upgrade


# Worst case scenario you'll have to un-install current version and Install a 
specific version.
$\> pip uninstall Django
$\> pip install Django==1.4.14 

More work to upgrade a bunch of virtuaenv's, but not as much as keeping all 
sites current, don't break your eco-system, unless there's a reason.

It's wise to choose a balance best practices that suit your eco-system.

I'd thank the team for issuing security releases for old versions.


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/1ddd5bbb-b2e6-4791-a92f-96bf997a9e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

2014-09-02 Thread Aymeric Augustin 
2014-09-02 15:33 GMT+02:00 Tom Evans :

> this story was scored
> at 8 points, it took a junior developer much longer than 8 points and
> wasn't finished in a single sprint - and 1.3->1.4 was *easy*
>

I don't know how much a point or a sprint is worth in this context :-/

I know that upgrading is very painful if you do it without following a
strict
process. Shotgun debugging is awful in this context. Here's the process I
would recommend.

1. Upgrade your dependencies. If possible (depending on how many you have)
check that they support the target Django version. Otherwise, you'll notice
at
step 3.

2. Read through the release notes. At each bullet point, do a quick check
for
affected code with "Find all in project" and fix it. It doesn't matter if
you
miss something at this stage. Provided you read every item, you'll make the
connection if you hit the problem. This is tedious, but if you do it another
way, you'll waste more time.

3. Run your test suite under -Wall or even -Werror until it's clean. Fix
stuff
you've missed until it passes.

Don't forget that, if your project didn't run cleanly under the previous
Django version, you need to start from the previous release notes and clear
deprecation warnings from your own code.

Did your junior developer follow a similar process? If he did, what took
them
so long?

What I want to understand is how much of an advantage I have when it comes
to
upgrading Django. What do I know that isn't written down and makes it so
hard
for others?

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CANE-7mV0tbQHf57B1H6YA6sSC95k-3GA97zbaCKCkX800P1b4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

2014-09-02 Thread Tom Evans 
On Mon, Sep 1, 2014 at 9:45 PM, Pkl  wrote:
>
> Hello,
>
> I once was once lured to an ideal of long-term stability and
> retrocompatibility, by nice docs like this one :
> https://docs.djangoproject.com/en/dev/misc/api-stability/
>
> But for some years, stuffs have actually been getting worse and worse, with
> each django release bringing its little crowd of nightmares.
>

Our solution is to not chase releases. Django 1.4 is marked as "Long
Term Stable", all our projects use Django 1.4 and no more; if/when a
newer stable release is proposed we will consider moving our projects
to that. We do then have some problems with 3rd party apps that do not
support 1.4..

There was a thread a few weeks ago that discussed (perhaps
tangentially) what the next LTS release branch will be, where it was
brought up that whatever release it is, the API will actually have to
be stable(!), probably ruling out 1.7. So, LTS will probably be 1.4
for some time yet.

On Tue, Sep 2, 2014 at 1:48 PM, Aymeric Augustin
 wrote:
> I'm not sure I understand completely where your frustration comes from. The
> tone of your email seems disproportionate with the effort needed to replace
> all instances of "django.conf.urls.defaults" with "django.conf.urls". That
> takes about ten minutes, if you count the time to locate the information in
> the release notes and make the commit.

It's not really, though is it? You encounter the problem because
you've upgraded django version; this will not be the only thing that
is broken, and so fixing this one thing will not enable you to run
your test suites.. it can take several iterations before you know that
it is fixed.

If you track django development and have used django for several
years, then these changes are relatively easy. If you are new to using
django, it is not so obvious and easy; as an example, we had an old
site running on django 1.3 that we wanted to move to 1.4 so that we
are using the same version of django throughout; this story was scored
at 8 points, it took a junior developer much longer than 8 points and
wasn't finished in a single sprint - and 1.3->1.4 was *easy*! We
prefer to spend our points on our own features (and senior developers
are expensive :)


Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/CAFHbX1%2BW2E0UO4kZZBwGHf%3DbA4%2BH4-u95T3jtGkUVX03ZOzQuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

2014-09-02 Thread Yo-Yo Ma 
With as many new frameworks as there are out there, with the gains in 
popularity seen in Go and Node, my thinking is, move quickly, break (some very 
small) things, or die slowly. As was said, if your favorite lib doesn't work 
with 1.6 or 1.7, either use a prior version, or spend some time contributing 
the 10 minutes to 2 hours that most of these changes would take at most. You'll 
feel good about it. You'll feel less frustrated, and you'll understand, 
thereafter, what it means to be an active part of the community. I too used to 
be a rail bird. It gets you "exactly nowhere", in the words of Russell K.M., 
and it makes those who contribute feel unappreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/ec509e6c-c72c-43f8-8d2d-eebc87347958%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Please don't kill the ecosystem

2014-09-02 Thread Aymeric Augustin 
Hello,

While I generally agree with what other core devs have said regarding the
examples you raised, I still find your feedback interesting because it
reminds us that we iterate too quickly for at least some parts of the
community.

It's unavoidable that some people will find the pace of Django's evolution
too fast and others will find it too slow. We're trying to ease the pain of
the former group by documenting thoroughly the changes in each release.

I'm not sure I understand completely where your frustration comes from. The
tone of your email seems disproportionate with the effort needed to replace
all instances of "django.conf.urls.defaults" with "django.conf.urls". That
takes about ten minutes, if you count the time to locate the information in
the release notes and make the commit. Is it a case of death by a thousand
cuts? Perhaps you could explain how you proceed when you need to upgrade
Django in your projects? Are the release notes somehow lacking?

Overall, I don't think we're going to change our pace — especially when it
comes to security-related issues — but we can try to improve our
communication around deprecations and removals.

-- 
Aymeric.

2014-09-01 22:45 GMT+02:00 Pkl :

>
> Hello,
>
> I once was once lured to an ideal of long-term stability and
> retrocompatibility, by nice docs like this one :
> https://docs.djangoproject.com/en/dev/misc/api-stability/
>
> But for some years, stuffs have actually been getting worse and worse,
> with each django release bringing its little crowd of nightmares.
>
> In random order, I stumbled upon:
> - removal of django.conf.urls.defaults
> - removal of markup contrib lib (adios built-in RST support)
> - removal of request.raw_post_data (thus breaking about all existing
> webservice libs)
> - lots of changes in mandatory settings, like allowed_hosts or DB conf
> format,
> - future removal of the very basic "mimetype" argument from django objects
> (how many apps impacted ? quite MANY I guess)
> - future removal of request.REQUEST (aka "we're not all consenting adults,
> let's remove all tools that people could misuse")
>
> For example, I had great fun installing django + djangocms + zinnia +
> cms_plugin_zinnia ; the probability of having no version mismatch between
> all these components being more or less zero.
>
> And the future looks grimmer again, having a look at
> https://docs.djangoproject.com/en/dev/internals/deprecation/.
>
> I don't get this relentlessness at breaking, for the sake of purity, all
> stuffs that are not actively maintained, yet could be perfectly working.
>
> What is easier, in a deeply dynamic language like python, than keeping
> retrocompatibility ? Why not keep "raw_post_data" as an undocumented alias
> for "body" ? Why not keep "mimetype" as a silent alias for "content_type" ?
> What harm did the "markup" support in django, since no one expects such
> extensions to be 100% secure anyway (no software on earth is) ? If code
> "purity" is wanted, then why not have all these monkey-patched from a
> builtin, but removable, "django.compatibility" util ? Why not wait for 2.0,
> to remove all compatibility aliases in one single shot ?
>
> The one killing features of django is its app ecosystem - being able to
> plug blogs, authentication systems, webservice generators, and all other
> kinds of applications, into this common framework, and benefit from the
> common auto-admin. And since all these apps don't evolve at the same rythm,
> retrocompatibility is IMHO a NECESSITY for django, not a LUXURY. Or isn't
> it ?
>
> Please don't kill the ecosystem, please respect the promises of
> api-stability that were once made.
>
> regards,
> Pkl
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/6abfd1ee-0056-41c1-b079-f89f2f463cf5%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aymeric.

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

Re: Please don't kill the ecosystem

2014-09-02 Thread Florian Apolloner 
Hi Pkl,

On Monday, September 1, 2014 10:45:30 PM UTC+2, Pkl wrote:
>
> In random order, I stumbled upon:
> - removal of django.conf.urls.defaults
> - removal of markup contrib lib (adios built-in RST support)
> - removal of request.raw_post_data (thus breaking about all existing 
> webservice libs)
> - lots of changes in mandatory settings, like allowed_hosts or DB conf 
> format, 
> - future removal of the very basic "mimetype" argument from django objects 
> (how many apps impacted ? quite MANY I guess)
> - future removal of request.REQUEST (aka "we're not all consenting adults, 
> let's remove all tools that people could misuse")
>

At least three of those are security related, if you read the api stability 
docs you will see that we will not consider api stability if this affects a 
security issue. If that creates an issue for you, then by all means Django 
is not for you. As for the other changes, I'd say they are debatable, but 
caused serious confusion for users (I am helping out on IRC quite a bit, so 
I was really glad to see them changed). At the speed we release Django, 
this gives you roughly two years to change your code, I think this is 
reasonable enough to ask for.

For example, I had great fun installing django + djangocms + zinnia + 
> cms_plugin_zinnia ; the probability of having no version mismatch between 
> all these components being more or less zero.
>

Oh, how so? They say to support Django 1.6 -- I doubt any of the above 
stated issues caused breakage there.
 

> I don't get this relentlessness at breaking, for the sake of purity, all 
> stuffs that are not actively maintained, yet could be perfectly working. 
>

If we would break for purity, we'd be breaking a lot more…
 

> What is easier, in a deeply dynamic language like python, than keeping 
> retrocompatibility ? Why not keep "raw_post_data" as an undocumented alias 
> for "body" ? Why not keep "mimetype" as a silent alias for "content_type" ?
>

For what? By the time we remove the feature from Django all apps should 
work with new Django versions. The older Django versions we are dropping 
support for by not keeping raw_post_data are no longer maintained and have 
__known__ and sometimes __easily__ exploitable security issues.

What harm did the "markup" support in django, since no one expects such 
> extensions to be 100% secure anyway (no software on earth is) ? 
>

No software on earth is 100% secure, but supporting something which has 
quite a few security implications and having to release security releases 
just for this component quite often isn't going to help. In the end users 
expect us to deliver secure code for known security issues in the third 
party libraries, this is not something we want to do.
 

> If code "purity" is wanted, then why not have all these monkey-patched 
> from a builtin, but removable, "django.compatibility" util ? Why not wait 
> for 2.0, to remove all compatibility aliases in one single shot ?
>

You feel up to this? This should work perfectly fine as 3rd party app, just 
don't expect us to maintain compatibility for releases which aren't even 
under security maintenance anymore.

The one killing features of django is its app ecosystem - being able to 
> plug blogs, authentication systems, webservice generators, and all other 
> kinds of applications, into this common framework, and benefit from the 
> common auto-admin. And since all these apps don't evolve at the same rythm, 
> retrocompatibility is IMHO a NECESSITY for django, not a LUXURY. Or isn't 
> it ?
>

Dunno, I usually never had problems. That said I only use relatively 
maintained apps, cause I want to be able to get bugs fixed "soonish".

Cheers,
Florian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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/ac4cd2d9-ed9b-4f9b-bd87-68ff5838ebcd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.