Re: passing additional context variables to project template

2012-05-05 Thread hirokiky 
Hi, Dominique.

It's right that you have said.
One bring up the topic on .

Quotation:
> I found the docs a little misleading when they say 'Any option passed to the 
> startapp command' will be added to the context.
> This got me thinking I could add arbitrary options to the command and pass 
> them in to the context, which would make for some
> highly configurable app/project boilerplates. But, from looking at the source 
> I gather by 'any options' they meant any valid options for the 
> startapp/project commands.

I think the discussion will help you.

-
hirokiky: Hiroki KIYOHARA.
http://hirokiky.org/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

passing additional context variables to project template

2012-05-05 Thread Dominique Guardiola Falco 
Sorry to cross-post this, as I just posted it on django-users, 
but it's perhaps a little problem with the django documentation here

I have a working project template that I can use with the new "--template" 
option of the startproject management command
I wanted to pass more variables in the template_context, and the doc [1] 
says  :

The template 
contextused
 is: 

   - *Any option passed to the startproject command*
   - project_name -- the project name as passed to the command
   - project_directory -- the full path of the newly created project
   - secret_key -- a random key for the 
SECRET_KEYsetting

But when I type for example  :
django-admin.py startproject --template=/home/admin/tmpl/ --myvar="hey" 
mynewprojectname
I get : django-admin.py: error: no such option: --myvar

TemplateCommand(BaseCommand) uses *optparse*, and from what I read on this 
module, it's normal that optparse refuses options that were not defined 
before ?
Am I missing a specific syntax to use here or does the documentation is 
wrong ?

Thanks for your help


[1] 
https://docs.djangoproject.com/en/1.4/ref/django-admin/#django-admin-startproject

Dominique Guardiola
http://www.quinode.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/QEIR-fl7n4wJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Test reordering and TransactionTestCase cleanup

2012-05-05 Thread Andreas Pelme 
On Saturday 5 May 2012 at 00:39, Anssi Kääriäinen wrote:
> On May 4, 2:30 pm, Karen Tracey  wrote:
> Thanks for the link. While reading the previous threads I spotted at
> one blocker issue: the first TransactionTestCase will not start with
> zeroed database sequence values. To prevent this one would need to
> flush the DB before the first TransactionTestCase. In addition, if the
> goal is to get rid of test ordering, then one would need to flush
> before every test case which isn't good. Getting rid of the
> requirement to reset sequences between test cases would be good.
> Oracle doesn't reset the sequences reliably currently just for
> example. But I don't think we can change that for backwards
> compatibility reasons. While tests that rely on sequence values are
> IMHO broken, changing this would result in numerous broken tests for
> users upgrading Django. Notably normal TestCases do not do sequence
> resetting at all currently.
>  
> This is a blocker: why change the flushing from pre-test to post-test
> if the end result is that you can't run the tests in arbitrary order
> anyways? Or if you want to be able to run them in arbitrary order you
> will need to run at least the sequence resets pre-test anyways.
> Resetting sequences can be really expensive, so there goes any
> potential savings in speed.
>  
> Ideas?

Agreed, it is indeed backward incompatible. However, I think we can make the 
upgrade for those affected very anyways:

 * Document this change properly in the release notes and in the testing docs
 * Document that tests should not depend on hard coded primary key values (this 
is already hinted in the testing docs where TestCase/TransactionTestCase is 
described)
 * Add a reset_sequences attribute on TransactionTestCase, that can be applied 
to existing TransactionTestCase tests that already uses hard coded primary key 
value - which will reset sequences *before* the test run, just like before. 
(And those tests will also flush the database after they are run)

I have updated the pull request with the reset_sequences attribute and an 
initial draft for the release notes and documentation:
https://github.com/django/django/pull/45

1.1 introduced a far greater change to testing behavior (the TestCase with 
transaction/rollback), if that change was considered acceptable from a backward 
compatibility perspective, this change should be too. When that happened, the 
same problem appeared since TestCase does not reset sequences. (Yeah, just 
because it was done in the past does not make it OK now, but that should give 
some perspective).

I guess it boils down to where to draw the line for backward compatibility 
here. :-) I personally think it is acceptable since we can offer a very easy 
fix for the existing (already broken) tests out there.


Andreas


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Test reordering and TransactionTestCase cleanup

2012-05-05 Thread Andreas Pelme 
On Friday 4 May 2012 at 13:30, Karen Tracey wrote:
> On Fri, May 4, 2012 at 4:46 AM, Andreas Pelme  (mailto:andr...@pelme.se)> wrote:
> > 
> > That's a good question. Anyone who wrote to original 
> > TransactionTestCase/reordering implementation that wants to chime in? :-)
> 
> I worked on the test speedups that introduced TransactionTestCase and
> I added the re-ordering, but the behavior of database flush being done
> at the beginning of a test existed before that work. The conversation
> that led to addition of the reordering is here:
> 
> http://groups.google.com/group/django-developers/browse_thread/thread/1e4f4c840b180895/
> 
> doctests (which we have no more?) play a prominent role in that
> discussion. While we have gotten rid of doctests in Django's own
> suite, we still support apps which may use doctests in their code, so
> anything we do to change when the DB is cleared needs to take that
> into account. On the table then was the idea of adding cleanup after
> doctests, possibly that would need to be re-considered if you want to
> move the database clearing to the end of everything rather than the
> beginning of TransactionTestCase.


#12408 is related here, which is caused by TransactionTestCase's not cleaning 
up after themselves. Rather than changing the test order to TestCase -> 
doctests -> TransactionTestCase I think the solution below is better.

Karens proposed a fix for this (#2) in the above thread [1], it basically says:

1) Make TransactionTestCase clean up after itself
2) Order the test suite to make sure doctests are always run *last*

That would run all unittest-style test cases first (the order of TestCase / 
TransactionTestCase will not be important), and last, all doctests.

A test suite that have doctests that *expects* state to be left from a 
TransactionTestCase before it would be broken by this change. In my opinion, a 
test suite with such expectations is already very broken and needs to be fixed 
any way, and should not be considered a blocker to this change (in that case, 
#12408 is a blocker too, since that effect will be the same).

I have updated my pull request to make unittest.TestCase subclasses to run 
first (i.e. doctests will run after all unit tests):
https://github.com/django/django/pull/45

Am I missing something? This seems like the most reliable way to solve this to 
me.

(I originally discovered this when I tried to run my tests with an alternative 
test runner, which does not order the tests in any particular way. I will still 
not be able to run doctests that does not clean up after themselves in 
arbitrary order, but as long as I document that's not supported with my test 
runner, I don't consider that to be a problem.)

Andreas

[1] https://groups.google.com/d/msg/django-developers/Hk9MhAsYCJU/fB4rj7F5SXEJ

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: How to serve staticfiles with full URL for local development?

2012-05-05 Thread Karen Tracey 
Please ask questions about using Django on django-users. The topic of
this list is the development of Django itself.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

How to serve staticfiles with full URL for local development?

2012-05-05 Thread lucky 
There was a snippet to display a content of response in browser during
debugging  http://miniblog.glezos.com/post/3388080372/tests-browser .

"One of the first issues you might face is seeing a style-less page.
This happens becuase the test server isn’t really a web server, and
you’re probably serving static files from something relative such as '/
site_media'. The solution is simple: Run a separate Django server and
tweak your development-only static URL to something like:

STATIC_URL = 'http://localhost:8000/site_media/
"

but this doesn't works anymore, because django.contrib.staticfiles
doesn't serve static when STATIC_URL contains full URL.

I found the node at 
https://docs.djangoproject.com/en/dev/howto/static-files/#serving-static-files-in-development
:

"That's because this view is grossly inefficient and probably
insecure. This is only intended for local development, and should
never be used in production.

Additionally, when using staticfiles_urlpatterns your STATIC_URL
setting can't be empty or a full URL, such as http://static.example.com/.;

Is there a way to omit this limitation for local development?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.