Re: Tagging 1.4 django release in Subversion

2012-03-26 Thread Łukasz Rekucki 
On 27 March 2012 03:01, Alex Gaynor  wrote:
>
>
> On Mon, Mar 26, 2012 at 9:00 PM, Łukasz Rekucki  wrote:
>>
>> On 27 March 2012 02:44, Reinout van Rees  wrote:
>> > On 26-03-12 18:13, Florian Apolloner wrote:
>> >>
>> >>
>> >>    I'm also intrigued how you have a release tarball before you have
>> >>    tagged the release!
>> >>
>> >> It's magic :ş
>> >
>> >
>> > Well, it is the kind of magic that gets you burned at the stake for
>> > witchcraft :-)
>> >
>>
>> That only means it must be effective ;)
>>
>>
>> As for the GitHub migration, I noticed this little repo[1]. Are you
>> collecting only major contributors or is it open for pull requests ?
>>
>>
>> [1]: https://github.com/brosner/django-git-authors
>>
>> --
>> Łukasz Rekucki
>>
>> --
>> 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.
>>
>
> As far as I understand, it's only needed for people with commits in the SVN
> repo.  (That is, commit authors, not patch contributors).
>

For a moment, I thought we could have some more of that magic and
amend the commits in git, so that "author" would be the patch
contributor and commit author would be the "committer". This should be
possible in most cases, as you only need to map the "Thanks " to an email address and github should do the rest.


> Alex
>


> --
> "I disapprove of what you say, but I will defend to the death your right to
> say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
>
> --
> 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.



-- 
Łukasz Rekucki

-- 
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: GSOC2012 Proposal for 'Finishing off the App Refactor'

2012-03-26 Thread Nauho Zen 
I have reformated my proposal content on this group, any suggestion?



Abstract
---

Django currently assumes that an application will only ever be loaded
once, and that the name of that application will be determined solely
by the package name holding the models.py. A gread idea has been
proposed as a GSOC idea in 2010[1] and continued in 2011[2], which
will improve the old app loading mechism a lot, e.g. deploy several
instances of the same application, deploy two applications with the
same name, support convenient interface for internationalizing
application names, etc. However, the [2] branch is not well prepared
for being merged to the master branch, and work been made in 2010 and
2011 towards these feathers has made some big changes to current
codebase, see[3]. So it's very necessary to check the changes and make
sure whether these work can be merged
and everything runs smoothly or not after merged.


Introduction
-

Because the purpose is to check if everything runs ok after merged, so
we should know what kind of features current app loading mechanism
supports and what kind of improvements 'future' advanced work has
made.

1 current app loading features
1) app can be reused in multiple projects
2) reused app can be found by Django in INSTALLED_APPS of settings.py,
which is written in dotted path
3) each string in INSTALLED_APPS should be a full Python path to a
Python package that contains a Django application, as created by
django-admin.py startapp
4) app names must be unique

2 'future' app loading features
1) backward compatibility: 'future' app loading mechanism should
support current app loading features well
2) can deploy several instaces of the same application
3) can deploy two applications with the same name,(not have the
requirements of unique app name)
4) convenient interface for internationalizing application names
5) good support to rename an application with a name that isn't
helpful from a UI
perspective

While,how to check these above, I think the best tool we can use is
unit-test. First,
we should check if all the funtions(get_apps, get_app,get_models,
etc.) still work after these changes, thus the test cases towards
these funtions should be run again to see if all is ok. Second, good
use cases should be establised to check if it still supports current
features well; we can borrow these use cases from previous work I
think. Third, also construct good use cases be used to check if will-
be-added features work well after merged, we can reuse the tests new
app-loading has offered.


But to the unittest point of view, we should pay more attention on the
files which has been modified. Specifically, except for the unittest
files, in [3], 6 files are
added, 20 files are modifiled. Thus one part important work is to
check if file changes does make bad or unexpected consequenses or not.
Towards unittest files, 21 files are added, 1 file is removed, 6 files
are modified, thus we also should check after these changes, whether
tests still cover old app loading unit test or not, what's more, cover
new features has been implemented in 2010 and 2011
well or not.


Detailed Plan:
Week 1: Read the source code corresponding with app loading of current
Django thoroughly, to know best what current app loading does and how
it does
Week 2: Read the source code of new app loading code, to check whether
it implement the new features interested developers proposed before
[4]
Week 3: Try to merge and check if old test cases can all be run
successfully, and make some necessary improvement work
Week 4-5: Establish good use cases to check if old app loading
features are all not been destroyed, meanwhile do necessary
modification work
Week 6: Check all new test cases can be run sucessfully or not, and
make some necessary work to help pass all tests
Week 7-8: Construct use cases to check how many new features have
already been implemented, and if there are some interesting features
that should be added, then I can do neccessary coding work
Week 9: make up current not well-done coding and tests work to make
app loading run perfectly
Week 10: Begin to create patches and create/write the documention
Week 11-12: Investigate the Django tickets host and contact with
corresponding and interested developers to know if there are some
necessary work or changes should be added , and if all is ok, try to
begin to submit the patches to Django


About me:
I am a student from China, and have about 3 years Python programming
skill and uses Django
for 2 years. I love this kind of activity Google has offered and am
very interested in
communicating with open source guys all over the world. Hope I can
make some contributions to Django through this wonderful activity.

Email: zenna...@gmail.com
IRC: zennauho


Links:

[1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[2]https://github.com/jezdez/django/commits/app-loading
[3]https://github.com/jezdez/django/compare/master...app-loading

Re: Tagging 1.4 django release in Subversion

2012-03-26 Thread Reinout van Rees 

On 27-03-12 02:47, James Bennett wrote:

On Mon, Mar 26, 2012 at 7:44 PM, Reinout van Rees  wrote:

>  Having a release before the tag? Sounds weird to me. Making a tag is
>  integral to the actual release, right? Curious:-)

The tag and the release package are both just the same revision from
trunk, so there is no requirement for the tag to exist in order to
release.

In this case we were holding off a bit to see if we could pull off the
GitHub migration quickly after the release, in which case it'd be one
less thing to migrate (easy enough to just tag the release once we get
it over there). But since that didn't happen, it's now been tagged in
SVN.


Good reason.

I'm looking forward to seeing how github plays out for Django. It'll be 
anything from a fun sociological experiment to a possible boost for 
participation. Really positively curious how it will play out.



Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Alex Gaynor 
On Mon, Mar 26, 2012 at 9:00 PM, Łukasz Rekucki  wrote:

> On 27 March 2012 02:44, Reinout van Rees  wrote:
> > On 26-03-12 18:13, Florian Apolloner wrote:
> >>
> >>
> >>I'm also intrigued how you have a release tarball before you have
> >>tagged the release!
> >>
> >> It's magic :ş
> >
> >
> > Well, it is the kind of magic that gets you burned at the stake for
> > witchcraft :-)
> >
>
> That only means it must be effective ;)
>
>
> As for the GitHub migration, I noticed this little repo[1]. Are you
> collecting only major contributors or is it open for pull requests ?
>
>
> [1]: https://github.com/brosner/django-git-authors
>
> --
> Łukasz Rekucki
>
> --
> 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.
>
>
As far as I understand, it's only needed for people with commits in the SVN
repo.  (That is, commit authors, not patch contributors).

Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

-- 
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Łukasz Rekucki 
On 27 March 2012 02:44, Reinout van Rees  wrote:
> On 26-03-12 18:13, Florian Apolloner wrote:
>>
>>
>>    I'm also intrigued how you have a release tarball before you have
>>    tagged the release!
>>
>> It's magic :ş
>
>
> Well, it is the kind of magic that gets you burned at the stake for
> witchcraft :-)
>

That only means it must be effective ;)


As for the GitHub migration, I noticed this little repo[1]. Are you
collecting only major contributors or is it open for pull requests ?


[1]: https://github.com/brosner/django-git-authors

-- 
Łukasz Rekucki

-- 
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread James Bennett 
On Mon, Mar 26, 2012 at 7:44 PM, Reinout van Rees  wrote:
> Having a release before the tag? Sounds weird to me. Making a tag is
> integral to the actual release, right? Curious :-)

The tag and the release package are both just the same revision from
trunk, so there is no requirement for the tag to exist in order to
release.

In this case we were holding off a bit to see if we could pull off the
GitHub migration quickly after the release, in which case it'd be one
less thing to migrate (easy enough to just tag the release once we get
it over there). But since that didn't happen, it's now been tagged in
SVN.

-- 
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Reinout van Rees 

On 26-03-12 18:13, Florian Apolloner wrote:


I'm also intrigued how you have a release tarball before you have
tagged the release!

It's magic :ş


Well, it is the kind of magic that gets you burned at the stake for 
witchcraft :-)


Having a release before the tag? Sounds weird to me. Making a tag is 
integral to the actual release, right? Curious :-)



Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
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: make the source code of the django tutorial available ?

2012-03-26 Thread Alex Ogier 
On Mon, Mar 26, 2012 at 7:28 PM, Russell Keith-Magee <
russ...@keith-magee.com> wrote:

> Once upon a time -- way back in Django's past -- we actually did have the
> tutorial code available as part of the Django repository. The problem was
> keeping the tutorial code and the tutorial itself in sync. If the two ever
> diverged (because someone made a change and forgot to update the code) or
> if there was ever an error in the code, then anyone doing the tutorial
> would get confused -- and that's the worst possible time to get confused,
> since it's our opportunity to convince someone how good Django is.
>
> There's also the problem that the tutorial goes through 4 steps, and it
> would be useful to have the code at the end of each step of the tutorial.
> Maintaining 4 tutorial codebases is also a time consuming process.
>

There's a middle ground: add enough metadata to the tutorial that its
instructions can be interpreted by a machine. One could imagine a build
script that parses the tutorial docs and produces four templates suitable
for 1.4's project templating system, in much the way that the ALFS
project takes
its build instructions from the Linux From Scratch documentation intended
for humans.

That said, it does seem counterproductive to give people shortcuts past the
fundamentals, especially when the fundamentals are already so carefully
curated. If you want the tutorial code as a reference, the tutorial itself
is an excellent textual description of all the changes made, so why not
just refer to that?

Best,
Alex Ogier

-- 
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: make the source code of the django tutorial available ?

2012-03-26 Thread Russell Keith-Magee 

On 27/03/2012, at 4:59 AM, Michael wrote:

> Hi,
> 
> I do not know if this is the right place so sorry if not.
> I am new to Django for a few months. I love the official django tutorial and 
> I went through it. 
> However, I actually never kept the whole tutorial source code on my PC so 
> after a while, when I wanted to look at a specific thing I saw in the 
> tutorial, I just felt bad that I had to do the whole tutorial again to get 
> the whole project working.
> So I created a public repository on github 
> (https://github.com/mike87/django-tuto) with the source code of the django 
> tutorial and I have thought that it might help people like me, being between 
> beginner and intermediate that just wanna go through the tutorial sometimes.
> 
> What do you think ? Would it be nice to mention the link at the end of the 
> tutorial on the documentation ?
> Could it help beginners ?

Hi Michael,

Thanks for the suggestion, but we've been down this path before and abandoned 
it.

Once upon a time -- way back in Django's past -- we actually did have the 
tutorial code available as part of the Django repository. The problem was 
keeping the tutorial code and the tutorial itself in sync. If the two ever 
diverged (because someone made a change and forgot to update the code) or if 
there was ever an error in the code, then anyone doing the tutorial would get 
confused -- and that's the worst possible time to get confused, since it's our 
opportunity to convince someone how good Django is.

There's also the problem that the tutorial goes through 4 steps, and it would 
be useful to have the code at the end of each step of the tutorial. Maintaining 
4 tutorial codebases is also a time consuming process.

Ultimately, the decision was made that there isn't *that* much code in the 
tutorial, so it was better to just have the text explanation, and get people to 
type the code. There's also a certain amount of evidence from education circles 
that this is a good idea anyway -- forcing someone to actually type the code 
(and therefore engage with the learning process) has benefits over just cutting 
and pasting some pre-prepared code.

Yours,
Russ Magee %-)

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

make the source code of the django tutorial available ?

2012-03-26 Thread Michael 
Hi,

I do not know if this is the right place so sorry if not.
I am new to Django for a few months. I love the official django tutorial 
and I went through it. 
However, I actually never kept the whole tutorial source code on my PC so 
after a while, when I wanted to look at a specific thing I saw in the 
tutorial, I just felt bad that I had to do the whole tutorial again to get 
the whole project working.
So I created a public repository on github (
https://github.com/mike87/django-tuto) with the source code of the django 
tutorial and I have thought that it might help people like me, being 
between beginner and intermediate that just wanna go through the tutorial 
sometimes.

What do you think ? Would it be nice to mention the link at the end of the 
tutorial on the documentation ?
Could it help beginners ?

That was just a thought to help the community.

Michael.






-- 
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/-/EnMEVi5lr-0J.
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.

GSOC2012 Proposal for 'Finishing off the App Refactor'

2012-03-26 Thread Nauho Zen 
Abstract
---

Django currently assumes that an application will only ever be loaded
once, and that
the name of that application will be determined solely by the package
name holding
the models.py. A gread idea has been proposed as a GSOC idea in
2010[1] and continued
in 2011[2], which will improve the old app loading mechism a lot, e.g.
deploy several
instances of the same application, deploy two applications with the
same name, support
convenient interface for internationalizing application names, etc.
However, the [2]
branch is not well prepared for being merged to the master branch, and
work been made in
2010 and 2011 towards these feathers has made some big changes to
current codebase, see[3].
So it's very necessary to check the changes and make sure whether
these work can be merged
and everything runs smoothly or not after merged.

Introduction
-

Because the purpose is to check if everything runs ok after merged, so
we
should know what kind of features current app loading mechanism
supports and what kind of
improvements 'future' advanced work has made.

1 current app loading features
1) app can be reused in multiple projects
2) reused app can be found by Django in INSTALLED_APPS of settings.py,
which is written in
dotted path
3) each string in INSTALLED_APPS should be a full Python path to a
Python package that
contains a Django application, as created by django-admin.py startapp
4) app names must be unique

2 'future' app loading features
1) backward compatibility: 'future' app loading mechanism should
support current app
loading features well
2) can deploy several instaces of the same application
3) can deploy two applications with the same name,(not have the
requirements of unique
app name)
4) convenient interface for internationalizing application names
5) good support to rename an application with a name that isn't
helpful from a UI
perspective

While,how to check these above, I think the best tool we can use is
unit-test. First,
we should check if all the funtions(get_apps, get_app,get_models,
etc.) still work after
these changes, thus the test cases towards these funtions should be
run again to see if all
is ok. Second, good use cases should be establised to check if it
still supports current
features well; we can borrow these use cases from previous work I
think. Third, also
construct good use cases be used to check if will-be-added features
work well after merged,
we can reuse the tests new app-loading has offered.

But to the unittest point of view, we should pay more attention on the
files which has been modified.
Specifically, except for the unittest files, in [3], 6 files are
added, 20 files are modifiled.
Thus one part important work is to check if file changes does make bad
or unexpected
consequenses or not. Towards unittest files, 21 files are added, 1
file is removed, 6 files
are modified, thus we also should check after these changes, whether
tests still cover old
app loading unit test or not, what's more, cover new features has been
implemented in 2010 and 2011
well or not.


Detailed Plan:
Week 1: Read the source code corresponding with app loading of current
Django thoroughly,
to know best what current app loading does and how it does
Week 2: Read the source code of new app loading code, to check whether
it implement the
new features interested developers proposed before [4]
Week 3: Try to merge and check if old test cases can all be run
successfully, and make
some necessary improvement work
Week 4-5: Establish good use cases to check if old app loading
features are all not been
destroyed, meanwhile do necessary modification work
Week 6: Check all new test cases can be run sucessfully or not, and
make some necessary
work to help pass all tests
Week 7-8: Construct use cases to check how many new features have
already been implemented,
and if there are some interesting features that should be added, then
I can do neccessary
coding work
Week 9: make up current not well-done coding and tests work to make
app loading run perfectly
Week 10: Begin to create patches and create/write the documention
Week 11-12: Investigate the Django tickets host and contact with
corresponding and interested
developers to know if there are some necessary work or changes should
be added , and if all
is ok, try to begin to submit the patches to Django


About me:
I am a student from China, and have about 3 years Python programming
skill and uses Django
for 2 years. I love this kind of activity Google has offered and am
very interested in
communicating with open source guys all over the world. Hope I can
make some contributions
to Django through this wonderful activity.

Email: zenna...@gmail.com
IRC: zennauho


Links:

[1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading
[2]https://github.com/jezdez/django/commits/app-loading
[3]https://github.com/jezdez/django/compare/master...app-loading
[4]https://code.djangoproject.com/wiki/InstalledAppsRevision

Re: Tagging 1.4 django release in Subversion

2012-03-26 Thread Florian Apolloner 
Hi Tom,

On Monday, March 26, 2012 5:59:45 PM UTC+2, Tom Evans wrote:
>
> Out of interest, is there any documentation of the release process?
>
Not sure if the process is documented in public somewhere, a quick search 
suggests no -- might be wrong.
 

> I'm also intrigued how you have a release tarball before you have
> tagged the release!
>
It's magic :þ

-- 
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/-/evpgva2WEDUJ.
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Johan 
>>good news: tag is there (https://code.djangoproject.com/changeset/17810)



Thanks!

 

>>Out of curiosity, what's the benefit of using an svn tag over the released
tarball?

 

For my project I need to apply some patches to the django code (eg for
#8280).  Applying a patch on svn checkout allows me to track my changes
better, and upgrade them between releases.

 

Johan

 

From: django-developers@googlegroups.com
[mailto:django-developers@googlegroups.com] On Behalf Of Florian Apolloner
Sent: Monday, March 26, 2012 5:48 PM
To: django-developers@googlegroups.com
Subject: Re: Tagging 1.4 django release in Subversion

 

Hi,

good news: tag is there (https://code.djangoproject.com/changeset/17810)

On Monday, March 26, 2012 6:05:47 AM UTC+2, Tai Lee wrote:

How come? The release that can be downloaded from the site already must
correspond to an SVN revision number, right? Why not tag it as such so that
people can easily get the same code from SVN as from the release tarball?


Out of curiosity, what's the benefit of using an svn tag over the released
tarball?


Cheers,
Florian 

-- 
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/-/dZ-7tRLAXswJ.
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.

-- 
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Tom Evans 
On Sun, Mar 25, 2012 at 12:02 PM, Florian Apolloner
 wrote:
> Hi,
>
> it's not tagged yet on purpose.
>
> Cheers,
> Florian
>

Out of interest, is there any documentation of the release process?
I'm also intrigued how you have a release tarball before you have
tagged the release!

Cheers

Tom

-- 
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: Tagging 1.4 django release in Subversion

2012-03-26 Thread Florian Apolloner 
Hi,

good news: tag is there (https://code.djangoproject.com/changeset/17810)

On Monday, March 26, 2012 6:05:47 AM UTC+2, Tai Lee wrote:
>
> How come? The release that can be downloaded from the site already must 
> correspond to an SVN revision number, right? Why not tag it as such so that 
> people can easily get the same code from SVN as from the release tarball?
>

Out of curiosity, what's the benefit of using an svn tag over the released 
tarball?

Cheers,
Florian 

-- 
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/-/dZ-7tRLAXswJ.
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: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

2012-03-26 Thread Byron Ruth 
I guess this would not be too different from how the `m2m_changed` signal 
works. The arguments would (at a bare minimum) include the `sender`, 
`action`, and `using`, then depending on the `action` other arguments may 
be passed in.

I would imagine if this approach would be taken, migrating existing signals 
over would follow the normal deprecation policy. But it could be introduced 
for the bulk-level operations initially without breaking any compatibility.

On Monday, March 26, 2012 4:00:14 AM UTC-4, Anssi Kääriäinen wrote:
>
> On 03/26/2012 06:34 AM, Byron Ruth wrote:
> > Sure I guess you _could_ take a generic signals approach to handling 
> > all modify operations, but for each operation context is important. 
> > The state of the object(s) matters when performing operations. The 
> > `pre_save` and `post_save` signals for example have a `created` flag 
> > which allows for filtering out the new objects versus existing ones. 
> > Likewise, having a distinct pair of delete signals ensures you don't 
> > make the mistake of performing operations on objects that are now 
> deleted.
>
> The pre/post_modify signal would have the context available. (parameters 
> action='save/delete/bulk_​create/update' and action_args). It would be 
> kind of all the current signals compressed into one. If that is a good 
> design or not is a good question. I think it would be useful, but I 
> would not be surprised if other core developers have different opinion 
> of such a signal.
>
> The reason the generic signal would be useful is that more often than 
> not you are interested in _all_ the data modifying operations done to a 
> model, not just in the save or delete or update subset. Hence, one mount 
> point for all the operations. What is done in the signal could be very 
> different for the .update() case than for the .save() case, but on the 
> other hand there are cases where the generic signal handler would reduce 
> the amount of work. For search engine reindexing (Haystack for example), 
> you would just do reindex(modified_objects) for all cases except delete. 
> Similar for cache invalidation. So, such a signal could simplify some 
> common operations.
>
> Having signals for all data modifying operations is in my opinion 
> important. It is of course possible to achieve this without generic 
> signals by just adding pre/post update / bulk_create signals. The 
> bulk_create signal is problematic because you do not have the auto-pk 
> values available even in post_bulk_create signal. For PostgreSQL and 
> Oracle having the PKs would be possible using the "RETURNING ID" syntax. 
> SQLite could be hacked to support returning the IDs (there are no 
> concurrent transactions, hence you know what the IDs will be, or at 
> least I think this is the case). But for MySQL I do not know of any way 
> of returning the IDs. Except for locking the table for the duration of 
> the insert...
>
>   - Anssi
>
>
>

-- 
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/-/16BAPV5h3FsJ.
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.

add support for PEP 302 importers

2012-03-26 Thread bhuztez 
I am working on fixing #14087. I think the biggest problem is that
django do not support PEP 302 importers. Also,  because of this,
tickets are marked as won't fix or fixed by introducing much more
implementation detail. It is not hard to find many of them, #582 #596
#8238 #8280 #12206 #13587 #16718 #17331. #13334 might be the only
exception. Add support for PEP 302 importers should fix most of them,
if not all.

-- 
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: Add signals for QuerySet bulk operations such as `delete`, `update, `bulk_create`

2012-03-26 Thread Anssi Kääriäinen 

On 03/26/2012 06:34 AM, Byron Ruth wrote:
Sure I guess you _could_ take a generic signals approach to handling 
all modify operations, but for each operation context is important. 
The state of the object(s) matters when performing operations. The 
`pre_save` and `post_save` signals for example have a `created` flag 
which allows for filtering out the new objects versus existing ones. 
Likewise, having a distinct pair of delete signals ensures you don't 
make the mistake of performing operations on objects that are now deleted.


The pre/post_modify signal would have the context available. (parameters 
action='save/delete/bulk_create/update' and action_args). It would be 
kind of all the current signals compressed into one. If that is a good 
design or not is a good question. I think it would be useful, but I 
would not be surprised if other core developers have different opinion 
of such a signal.


The reason the generic signal would be useful is that more often than 
not you are interested in _all_ the data modifying operations done to a 
model, not just in the save or delete or update subset. Hence, one mount 
point for all the operations. What is done in the signal could be very 
different for the .update() case than for the .save() case, but on the 
other hand there are cases where the generic signal handler would reduce 
the amount of work. For search engine reindexing (Haystack for example), 
you would just do reindex(modified_objects) for all cases except delete. 
Similar for cache invalidation. So, such a signal could simplify some 
common operations.


Having signals for all data modifying operations is in my opinion 
important. It is of course possible to achieve this without generic 
signals by just adding pre/post update / bulk_create signals. The 
bulk_create signal is problematic because you do not have the auto-pk 
values available even in post_bulk_create signal. For PostgreSQL and 
Oracle having the PKs would be possible using the "RETURNING ID" syntax. 
SQLite could be hacked to support returning the IDs (there are no 
concurrent transactions, hence you know what the IDs will be, or at 
least I think this is the case). But for MySQL I do not know of any way 
of returning the IDs. Except for locking the table for the duration of 
the insert...


 - Anssi


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