Re: unittest.TestCase vs. django.test.TestCase in overview example

[Brian Schott]

There is really a bigger question in my mind about the appropriateness of using 
django.utils.unittest in the testing overview section.  It is an optimization 
that the warning admits is fairly limited for real testing and is premature for 
the first example.  It would be better to break out the optimization as a Note 
"if your tests don't rely on database access, you can ... optimize with 
django.utils import...".  The testing overview section should import the class 
that works correctly when testing Animal.objects.create() or self.lion.save().

It's also not a case of catering.  Enclosed is a link to a screen shot that 
starts with "Writing tests" and ends with "For more details about unittest, see 
the Python documentation".
https://www.dropbox.com/s/9eh2zgkxphc5rvo/django_test_doc_screen.png
Nowhere on that first screen of documentation on a 20 inch monitor does it 
refer to django.test.TestCase and "For more details..." reads like the end of 
the section.  It's really easy to not see the warning and the first two 
examples of what someone glancing at the docs to manually create a tests.py 
file will read is "from django.utils import unittest". which causes a very 
non-obvious unit test failures in the most typical test cases.  

Thanks for reconsidering the patch!  Lorin's version is much clearer.
Brian

On Mar 25, 2013, at 2:08 PM, Tim Graham  wrote:

> It seems like it could be a dangerous precedent to cater to people who don't 
> take the time to fully read the docs, but in this case I'm a bit sympathetic. 
> On the other hand, this example will probably be a bit more obvious when we 
> drop support for Python 2.6 and no longer have django.utils.unittest. At the 
> least, we could probably move the warning above the example so it's a bit 
> more visible.
> 
> On Saturday, March 16, 2013 8:27:01 PM UTC-4, Lorin Hochstein wrote:
> Hi there:
> 
> On the Django testing overview doc page 
> , the initial 
> example uses unittest.TestCase. A Django developer who was looking for a 
> quick reminder on how to write unit tests is likely to hit this page first. 
> If that developer doesn't read the "warning" section below, they could 
> mistakenly use unittest.TestCase when their unit tests change  the database. 
> This very scenario happened to a colleague of mine.
> 
> I proposed changing this to django.test.TestCase 
> , but that pull request with 
> closed out by Aymeric Augustin, with reference to 
> . I don't think ticket #15986 
> covers quite the same issue, despite its title. Django devs, can you 
> reconsider this doc patch?
> 
> Take care,
> 
> Lorin
> 
> 
> -- 
> 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

[Amirouche Boubekki]

>
> [1] http://amirouche.github.com/blog/django-admin-next-a-new-api.html
>

this doesn't work anymore I moved @
http://blog-amirouche.dotcloud.com/notes/2013/admin-next-a-new-api.html

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Kickstarter for Django Admin?

[Amirouche Boubekki]

2013/3/30 Victor Hooi 

> heya,
>
> Aha, yes - we need a roadmap, and somebody from the team to execute it
> *grins*.
>
> For the former - I believe there was already discussions on that sort of
> thing on this board?
>
> There's a wiki page with some notes as well:
>
> https://code.djangoproject.com/wiki/AdminNext
>
> I also had a look at some of the existing projects:
>
>- https://github.com/yawd/yawd-admin
>- https://github.com/michaelhelmick/django-bootstrap-admin (Doesn't
>appear to be too active)
>- https://github.com/riccardo-forina/django-admin-bootstrapped
>- https://github.com/aobo711/bootstrap-django-admin
>- 
> https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap(Doesn't 
> appear to be too active)
>- https://github.com/divio/djangocms-admin-style
>
> And there's obviously Grapelli.
>
> A lot of these are obviously just reskins, while others offer a bit more.
>
> From the existing projects, we can draw two clear requirements that people
> want:
>
>- Changing the look and feel - I'm not sure what Django core's
>feelings on it, but there seems to be a feeling from the community that the
>look of the current Django Admin is somewhat dated? Also, any new admin
>should probably be responsive, and work on mobile or non-desktop devices,
>if that's possible.
>
>
This question leads to another should Django develop its own css framework
and re-use existing one, if Django use an existing one, Django must make it
easy to work with the preprocessor. While I liked much bootstrap,
foundation's mobile first approach of Foundation is appealing even if more
verbose.


>
>- More customisations -  a lot of people want to create dashboards
>around the admin, add new sections/tabs, or move things around - the
>current Admin doesn't have much scope for that, or it's not easily
>accessible.
>
> Those are all things that are doable right now. I though it was about
something more «disruptive» that's why I called the page AdminNext to
follow the naming of next html version... whatever the naming, the goal
should be the same aka. not only a cbv-Admin which should only adress the
customisability (and readability) side but add features. This lead me to
the group/permission-centric admin which creates menu based on permissions,
but I did not implement it. I've documented a sketch API [1], but I'm not
very happy with it, I'm now thinking about something in the spirit of
lettuce to create an admin.

I stopped working on the composite admin because a) the composite thing is
too much b) I wasn't confortable with the code handling inlines in current
admin so I started thinking about fixing it but got stuck (!).

Also there is this conversation that is somehow related:
https://groups.google.com/forum/#!msg/django-developers/wI18E6BZImQ/TS2wSvUCkaAJ

Maybe Django should gather money somehow and tell a company to do the job
instead of relying on the community ?

HTH,

Amirouche

[1] http://amirouche.github.com/blog/django-admin-next-a-new-api.html



> For the latter, not sure I can help you there...lol. I thought Idan Gazit
> was working on something before though? Or are there other designers on the
> Core team?
>
> Cheers,
> Victor
>
> On Sunday, 24 March 2013 22:14:58 UTC+11, Russell Keith-Magee wrote:
>
>>
>> On Sun, Mar 24, 2013 at 6:20 PM, Victor Hooi  wrote:
>>
>>> Hi,
>>>
>>> I read recently about Andrew Goodwin's successful kickstarter project
>>> for better Django schema migrations:
>>>
>>> http://www.kickstarter.com/**projects/andrewgodwin/schema-**
>>> migrations-for-django
>>>
>>> Kudos to him for awesome work on South so far a swell =).
>>>
>>> There doesn't seem to be much movement on the Admin front -
>>> https://groups.google.com/d/**msg/django-developers/**
>>> Vozu6U3gz84/vvbTqrWitxIJ
>>>
>>> I'm wondering - is there any impetus for a similar kickstarter for the
>>> Django admin?
>>>
>>> I for one would be willing to put my money where my mouth is and back it
>>> - and I'm sure other people/companies who use Django in their own projects
>>> would as well.
>>>
>>
>> Good to hear :-)
>>
>> There's one significant difference here. Andrew's project was to deliver
>> South-like functionality to trunk. South is a known quantity, and there
>> have been discussions and threads about exactly what merging South into
>> trunk would look like. And on top of all that, Andrew is the principle
>> author of South, so he's well positioned to do the work.
>>
>> What's the feature set for a new Admin? What are the design goals? And
>> most importantly, who is going to do the work?
>>
>> I'm not saying these questions can't be answered -- but the answers
>> aren't clear at the moment (at least, not to me). Once we've got a clear
>> plan, and someone who is 

Re: Kickstarter for Django Admin?

[Victor Hooi]

heya,

Aha, yes - we need a roadmap, and somebody from the team to execute it 
*grins*.

For the former - I believe there was already discussions on that sort of 
thing on this board?

There's a wiki page with some notes as well:

https://code.djangoproject.com/wiki/AdminNext

I also had a look at some of the existing projects:

   - https://github.com/yawd/yawd-admin
   - https://github.com/michaelhelmick/django-bootstrap-admin (Doesn't 
   appear to be too active)
   - https://github.com/riccardo-forina/django-admin-bootstrapped
   - https://github.com/aobo711/bootstrap-django-admin
   - https://github.com/gkuhn1/django-admin-templates-twitter-bootstrap 
   (Doesn't appear to be too active)
   - https://github.com/divio/djangocms-admin-style

And there's obviously Grapelli.

A lot of these are obviously just reskins, while others offer a bit more.

>From the existing projects, we can draw two clear requirements that people 
want:

   - Changing the look and feel - I'm not sure what Django core's feelings 
   on it, but there seems to be a feeling from the community that the look of 
   the current Django Admin is somewhat dated? Also, any new admin should 
   probably be responsive, and work on mobile or non-desktop devices, if 
   that's possible.
   - More customisations -  a lot of people want to create dashboards 
   around the admin, add new sections/tabs, or move things around - the 
   current Admin doesn't have much scope for that, or it's not easily 
   accessible.

For the latter, not sure I can help you there...lol. I thought Idan Gazit 
was working on something before though? Or are there other designers on the 
Core team? 

Cheers,
Victor

On Sunday, 24 March 2013 22:14:58 UTC+11, Russell Keith-Magee wrote:
>
>
> On Sun, Mar 24, 2013 at 6:20 PM, Victor Hooi  > wrote:
>
>> Hi,
>>
>> I read recently about Andrew Goodwin's successful kickstarter project for 
>> better Django schema migrations:
>>
>>
>> http://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django
>>
>> Kudos to him for awesome work on South so far a swell =).
>>
>> There doesn't seem to be much movement on the Admin front - 
>> https://groups.google.com/d/msg/django-developers/Vozu6U3gz84/vvbTqrWitxIJ
>>
>> I'm wondering - is there any impetus for a similar kickstarter for the 
>> Django admin?
>>
>> I for one would be willing to put my money where my mouth is and back it 
>> - and I'm sure other people/companies who use Django in their own projects 
>> would as well.
>>
>
> Good to hear :-)
>
> There's one significant difference here. Andrew's project was to deliver 
> South-like functionality to trunk. South is a known quantity, and there 
> have been discussions and threads about exactly what merging South into 
> trunk would look like. And on top of all that, Andrew is the principle 
> author of South, so he's well positioned to do the work.
>
> What's the feature set for a new Admin? What are the design goals? And 
> most importantly, who is going to do the work?
>
> I'm not saying these questions can't be answered -- but the answers aren't 
> clear at the moment (at least, not to me). Once we've got a clear plan, and 
> someone who is available to deliver on that plan, then a Kickstarter might 
> be appropriate.
>
> Yours,
> Russ Magee %-)
>
>
>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Testing project code that resides outside of installed apps

[Carl Meyer]

Hi,

On 03/30/2013 10:32 AM, Yo-Yo Ma wrote:
> A common pattern for larger applications is to maintain bits of reusable
> code outside of applications, but still inside of a project (e.g.,
> myproject/lib), due to synchronous development and modification of
> application and library code. They're parts that aren't really large
> enough to warrant their own pip-installable package, but large enough to
> need tests.
> 
> Often, the (non-)solution is either to NOT test these small tools at
> all, or to test them in a way that tightly couples them to one's
> applications.
> 
> I'm here to get feedback on the general idea of a solution to the
> aforementioned problem, and on the acceptability (by the community) of
> such situations (maintaining libs outside of applications but still
> inside of a project):
> 
> 1) Is there merit to (Django) providing a way to specify a project-level
> tests package/module wherein tests could be imported from various places
> in your project?
> OR
> 2) Is this something that should always remain in a custom test runner?
> OR
> 3) Is this sort of code maintenance just not a great idea because
> libraries that need tests should be factored out as pip-installable
> packages and independently tested?
> 
> If this is considered a good practice AND the answer to #1 is something
> akin to "yes", feel free to make suggestions on what you think the API
> (or setting, etc.) should look like.

I think the answer to this is
https://code.djangoproject.com/ticket/17365 -- we are already planning
to replace the current app-based test discovery with the more standard
test discovery mechanism from unittest2, which will be able to find
tests anywhere (in any file whose name begins with "test"), not only in
INSTALLED_APPS.

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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

[Shai Berger]

On Tuesday 19 March 2013, Florian Apolloner wrote:
> Hi,
> 
> On Tuesday, March 19, 2013 8:21:05 AM UTC+1, Shai Berger wrote:
> > Is there any interest in fixing this, specifically?
> 
> Sure, I just don't have to knowledge to debug cx_Oracle, so if you are up
> to please. Although I think the endresult would most likely be a patch to
> cx_Oracle and not Django.
> 
I had meant, is there interest in solving it on Ubuntu 11.10 -- things like 
segfaults are sometimes related to specific versions of libraries and even 
compilers.

But I was able to generate a segfault also on my main work machine, a Debian 
Testing. It even seems much worse there. So it will be a little easier for me 
to work on, and there may be some more motivation for others to work on it.

Thanks,
Shai.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: unittest.TestCase vs. django.test.TestCase in overview example

[Lorin Hochstein]

Will dropping support for Python 2.6 have any effect here? I assumed the 
example would just switch to using unittest.TestCase instead of 
django.utils.unittest.TestCase, and the usability issue would remain.

I think having the warning above the example would help, but I'd still 
prefer having the (slower but less likely to cause an error in a different 
context) django.test.TestCase used in the initial example.


On Monday, March 25, 2013 2:08:54 PM UTC-4, Tim Graham wrote:
>
> It seems like it could be a dangerous precedent to cater to people who 
> don't take the time to fully read the docs, but in this case I'm a bit 
> sympathetic. On the other hand, this example will probably be a bit more 
> obvious when we drop support for Python 2.6 and no longer have 
> django.utils.unittest. At the least, we could probably move the warning 
> above the example so it's a bit more visible.
>
> On Saturday, March 16, 2013 8:27:01 PM UTC-4, Lorin Hochstein wrote:
>>
>> Hi there:
>>
>> On the Django testing overview doc page <
>> https://docs.djangoproject.com/en/dev/topics/testing/overview/>, the 
>> initial example uses unittest.TestCase. A Django developer who was looking 
>> for a quick reminder on how to write unit tests is likely to hit this page 
>> first. If that developer doesn't read the "warning" section below, they 
>> could mistakenly use unittest.TestCase when their unit tests change  the 
>> database. This very scenario happened to a colleague of mine.
>>
>> I proposed changing this to django.test.TestCase <
>> https://github.com/django/django/pull/903>, but that pull request with 
>> closed out by Aymeric Augustin, with reference to <
>> https://code.djangoproject.com/ticket/15896>. I don't think ticket 
>> #15986 covers quite the same issue, despite its title. Django devs, can you 
>> reconsider this doc patch?
>>
>> Take care,
>>
>> Lorin
>>
>>

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Testing project code that resides outside of installed apps

[Yo-Yo Ma]

A common pattern for larger applications is to maintain bits of reusable 
code outside of applications, but still inside of a project (e.g., 
myproject/lib), due to synchronous development and modification of 
application and library code. They're parts that aren't really large enough 
to warrant their own pip-installable package, but large enough to need 
tests.

Often, the (non-)solution is either to NOT test these small tools at all, 
or to test them in a way that tightly couples them to one's applications.

I'm here to get feedback on the general idea of a solution to the 
aforementioned problem, and on the acceptability (by the community) of such 
situations (maintaining libs outside of applications but still inside of a 
project):

1) Is there merit to (Django) providing a way to specify a project-level 
tests package/module wherein tests could be imported from various places in 
your project?
OR
2) Is this something that should always remain in a custom test runner?
OR
3) Is this sort of code maintenance just not a great idea because libraries 
that need tests should be factored out as pip-installable packages and 
independently tested?

If this is considered a good practice AND the answer to #1 is something 
akin to "yes", feel free to make suggestions on what you think the API (or 
setting, etc.) should look like.

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: javascript view for named urls

[Bernhard Ja]

Am Freitag, 29. März 2013 21:05:05 UTC+1 schrieb Andrew Ingram:

>
> I like the concept of this, because it's something I've often wanted 
> myself. But I want to bring up a couple of points: 
>
> 1) Some websites rely on the obscurity of some of their URLs as an 
> additional security measure (i.e. have the admin at something other than 
> /admin/). This is admittedly not a great measure, since a persistent 
> attackers will probably get around it. But the key would be a way to manage 
> which patterns get included in the javascript catalog, possibly even having 
> it configurable at the the view level so that some templates can request a 
> different subset of the patterns to others. 
>

I agree. A way to manage the existenz in the js catalog is necessary.
 

> 2) It'd be nice if it could be integrated with internationalisation, so 
> that if you're using Django's i18n_patterns, the view automatically fills 
> in the country segment based on the request's locale. Much like the 
> translation string view only returns the strings for the request's 
> language. 
>

 I did some tests and the language code prefix appears in the generated 
urls. Am i missing sth.?

Whats the best was to propose this feature for the django core? 

Bye, Boerni

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

loaddata --ignorenonexistent not working for XML based fixtures

[Christoph Sieghart]

Hey,

three weeks ago I posted a patch and test. I just asked on IRC what to do 
to get things moving, and I was told to post
to the mailing list about it.

The issue is:
  https://code.djangoproject.com/ticket/19998

Patch and tests are included.

best regards,
Christoph

-- 
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.