Re: Cleaning up manage.py and import paths
On Tue, Oct 11, 2011 at 02:06, Luke Plant wrote:
> On 10/10/11 23:05, Carl Meyer wrote:
>
> > Unless there are significant objections, I'd like to commit this in the
> > next few days and get it into 1.4. I'll also modify the patch on #16360
> > to take advantage of the new layout; hopefully that can get into 1.4 as
> > well.
>
>
Definitely +1, as this has bitten me far too often. It would be nice however
to also depend less on the ('hacky', as Glyph also noted)
DJANGO_SETTINGS_MODULE environment variable. We shouldn't need an env
variable to run a python website, and it certaintly shouldn't screw up
settings loading when set accidently. The new proposed setup_settings
function accepts a path, but listens to the env variable first, and if that
is not set it it wil still try to load 'settings'. Why not listen to the
path that is provided so I can pass 'mysite.settings.production' for
example? And if it's not provided, listen to DJANGO_SETTINGS_MODULE for
backwards compatibility.
Tino
--
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: Cleaning up manage.py and import paths
2011/10/11 Carl Meyer :
> Unless there are significant objections, I'd like to commit this in the
> next few days and get it into 1.4. I'll also modify the patch on #16360
> to take advantage of the new layout; hopefully that can get into 1.4 as
> well.
>
> Let me know if you see something I've overlooked!
Carl,
+1 from me too.
The new structure highlights that a Django project is:
- an entrypoint for scripts manage.py — and soon another one for WSGI servers,
- a settings module and a root URLconf, who happen to live in the same
package by default,
- some applications, templates, static files, etc.
I was about to ask a question about the recommended project layout but
I eventually found the answer here:
https://github.com/carljm/django/commit/4ba999060d8c030dd43ef4a8ec2844850f0310b3#L2R380
This information will still be interesting and useful long after the
1.4 release. Shouldn't we move it somewhere in the documentation and
link to that page from the release notes?
Also, following the Zen of Python, shouldn't we recommend the
decoupled style (ie. put apps in the outer "mysite" directory)?
Finally, if I understand correctly, the only reason why the default
settings and URLconf are in a package ("mysite.settings" and
"mysite.urls") is to avoid name conflicts. In particular, it makes it
possible to run several Django projects in parallel with the same
PYTHONPATH. It'd be worth mentioning this in the documentation, so
that newcomers understand there's nothing magic with the name of the
inner "mysite" directory.
I believe all this could go either in the tutorial or in a new page
dedicated to project layout — the latter would allow us to give more
details on the project layout options.
Thanks for your work on this long-standing issue!
--
Aymeric.
--
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: Cleaning up manage.py and import paths
On 11 October 2011 02:06, Luke Plant wrote: > On 10/10/11 23:05, Carl Meyer wrote: > >> Unless there are significant objections, I'd like to commit this in the >> next few days and get it into 1.4. I'll also modify the patch on #16360 >> to take advantage of the new layout; hopefully that can get into 1.4 as >> well. I already do it this way except the manage.py is vanilla. project-package/ project.wsgi requirements.txt setup.py .git bin/ # virtualenv ... project/ __init__.py manage.py settings.py urls.py ... HM -- 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.
Having Django supporting IDEs represented at http://djangoproject.com/
Hello, At the moment, the Django site doesn't provide any guidance about the development tools (editors or IDEs) that can be used for developing Django applications. There are already a number of IDEs with good Django support (disclaimer: I'm the lead developer on one of them, namely PyCharm), and I think that it would be very helpful, at least for novice developers, to provide links to such tools. The Ruby on Rails site does a great job at that, in my opinion: http://rubyonrails.org/ecosystem I've discussed this with Russell Keith-Magee during DjangoCon.EU, and he seemed to be in favor of this. Does the community think that it's worthwhile? Is there anything specific we can do to get this moving? I can submit a proposed patch to the documentation if that's an acceptable approach. Thanks in advance! Dmitry -- 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: Having Django supporting IDEs represented at http://djangoproject.com/
On Tue, Oct 11, 2011 at 7:27 AM, Dmitry Jemerov wrote: > I've discussed this with Russell Keith-Magee during DjangoCon.EU, and he > seemed to be in favor of this. Does the community think that it's > worthwhile? Is there anything specific we can do to get this moving? > > I can submit a proposed patch to the documentation if that's an acceptable > approach. Great idea! Good timing, too: I'm teaching an intro to Django class this week, and my students are very interested in advice on IDEs. Unfortunately, I'm not an IDE kind of guy, so about the best advice I can give them is "um, I think you can use Eclipse? Oh and maybe that PyCharm thing? Right?" So, yes, I'd love to see some pointers to editors. A page in the docs with some pointers and brief setup instructions would be very nice, I think. Something somewhat like what we're already doing with deployment: a basic intro to common tools, then a pointer to more information. If you'd like to start collecting information and links that would be a fantastic addition. Keep me posted so I can review your work (and perhaps add to it if I can find the time). As for the broader "Django ecosystem" page: also a great idea. I'm working away at a huge "improve djangoproject.com" todo list, but hey what's one more good idea? I'd be happy to take contributions here, too, but I'm going to be a bit more picky about what shows up on the "main" site, so expect it to take a bit more review and tweaking before it goes live. Thanks! Jacob -- 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: Having Django supporting IDEs represented at http://djangoproject.com/
On Tue, Oct 11, 2011 at 9:21 AM, Jacob Kaplan-Moss wrote: > On Tue, Oct 11, 2011 at 7:27 AM, Dmitry Jemerov > wrote: > > I've discussed this with Russell Keith-Magee during DjangoCon.EU, and he > > seemed to be in favor of this. Does the community think that it's > > worthwhile? Is there anything specific we can do to get this moving? > > > > I can submit a proposed patch to the documentation if that's an > acceptable > > approach. > > Great idea! > > Good timing, too: I'm teaching an intro to Django class this week, and > my students are very interested in advice on IDEs. Unfortunately, I'm > not an IDE kind of guy, so about the best advice I can give them is > "um, I think you can use Eclipse? Oh and maybe that PyCharm thing? > Right?" > > So, yes, I'd love to see some pointers to editors. A page in the docs > with some pointers and brief setup instructions would be very nice, I > think. Something somewhat like what we're already doing with > deployment: a basic intro to common tools, then a pointer to more > information. If you'd like to start collecting information and links > that would be a fantastic addition. Keep me posted so I can review > your work (and perhaps add to it if I can find the time). > > As for the broader "Django ecosystem" page: also a great idea. I'm > working away at a huge "improve djangoproject.com" todo list, but hey > what's one more good idea? I'd be happy to take contributions here, > too, but I'm going to be a bit more picky about what shows up on the > "main" site, so expect it to take a bit more review and tweaking > before it goes live. > > Thanks! > > Jacob > > -- > 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. > > I hate to use the "w" word, but this seems infinitely better as a wikipage. For one we avoid any appearance of endorsement (and given the diversity of options in this space, that's not a bad thing). Second, it allows for much more comprehensive information. In addition to just "what text editor/IDE" there are also a myriad of questions surrounding the correct usage of plugins (i.e. it's not fair to compare PyCharm to VIM, it's fair to compare PyCharm to VIM with 700 plugins). Trying to make this an official doc page will, I fear, lead to a pile of tickets asking for slight changes to feature one plugin, or theme, or whatever else, with no way for core developers to actually know which is preferred unless they happen to use that editor. 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: Having Django supporting IDEs represented at http://djangoproject.com/
2011/10/11 Alex Gaynor : > I hate to use the "w" word, but this seems infinitely better as a wikipage. I agree with Alex: I'd prefer if this information was community-managed. A quick search turns up: https://code.djangoproject.com/wiki/DjangoResources#Developmentenvironment https://code.djangoproject.com/wiki/TextMate https://code.djangoproject.com/wiki/UsingVimWithDjango These pages aren't sufficiently structured yet, but it's mostly a matter of listing the N most popular solutions in an index page, and creating a page for each of them. For what it's worth my team uses vim, emacs, TextMate, Sublime Text, PyCharm, Eclipse :) Best regards, -- Aymeric. -- 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: Having Django supporting IDEs represented at http://djangoproject.com/
Hello, I think it's a great iniciative. It would be great to have something like that. Maybe the perfect place is the wiki. IMHO something like the DjangoFriendlyWebHosts [1] would be a good approach. [1] https://code.djangoproject.com/wiki/DjangoFriendlyWebHosts On Tue, Oct 11, 2011 at 1:27 PM, Dmitry Jemerov wrote: > Hello, > > At the moment, the Django site doesn't provide any guidance about the > development tools (editors or IDEs) that can be used for developing Django > applications. There are already a number of IDEs with good Django support > (disclaimer: I'm the lead developer on one of them, namely PyCharm), and I > think that it would be very helpful, at least for novice developers, to > provide links to such tools. > > The Ruby on Rails site does a great job at that, in my opinion: > http://rubyonrails.org/ecosystem > > I've discussed this with Russell Keith-Magee during DjangoCon.EU, and he > seemed to be in favor of this. Does the community think that it's > worthwhile? Is there anything specific we can do to get this moving? > > I can submit a proposed patch to the documentation if that's an acceptable > approach. > > Thanks in advance! > Dmitry > > -- > 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. > -- Esaú Rodríguez esa...@gmail.com -- 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: Having Django supporting IDEs represented at http://djangoproject.com/
Hello Alex, On Oct 11, 3:25 pm, Alex Gaynor wrote: > I hate to use the "w" word, but this seems infinitely better as a wikipage. > For one we avoid any appearance of endorsement (and given the diversity of > options in this space, that's not a bad thing). Second, it allows for much > more comprehensive information. In addition to just "what text editor/IDE" > there are also a myriad of questions surrounding the correct usage of > plugins (i.e. it's not fair to compare PyCharm to VIM, it's fair to compare > PyCharm to VIM with 700 plugins). Trying to make this an official doc page > will, I fear, lead to a pile of tickets asking for slight changes to feature > one plugin, or theme, or whatever else, with no way for core developers to > actually know which is preferred unless they happen to use that editor. I'm completely in favor of having all the specific information on a Wiki page, but I still think it's worth linking to that page from the introductory documentation (a note in the tutorial, a question in the FAQ and maybe some other places). Dmitry -- 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi TiNo,
On 10/11/2011 06:10 AM, TiNo wrote:
> Definitely +1, as this has bitten me far too often. It would be nice
> however to also depend less on the ('hacky', as Glyph also noted)
> DJANGO_SETTINGS_MODULE environment variable. We shouldn't need an env
> variable to run a python website, and it certaintly shouldn't screw up
> settings loading when set accidently.
I'd certainly like to get rid of DJANGO_SETTINGS_MODULE in the long run,
but I don't see how we can do so without also getting rid of
process-global settings, and that's a much bigger project and patch, far
out of scope for what I'm attempting here.
As long as we have process-global settings, we need an explicit way for
users to specify which settings module they want to use, that is
possible to provide across a variety of different ways of invoking a
process (including e.g. having it implicitly invoked by mod_wsgi, in
which case some other options, like command-line parameters, are not
available). Having multiple settings modules available and picking one
for a given invocation is a feature, and an important one for many
people. If you have a proposal for a better way to do that than
DJANGO_SETTINGS_MODULE, that can be implemented in a
backwards-compatible way, we can certainly discuss it - but it doesn't
need to hold up this patch.
The new proposed setup_settings
> function accepts a path, but listens to the env variable first, and if
> that is not set it it wil still try to load 'settings'. Why not listen
> to the path that is provided so I can pass 'mysite.settings.production'
> for example? And if it's not provided, listen to DJANGO_SETTINGS_MODULE
> for backwards compatibility.
The "setup_settings" function is not a part of my proposed patch for
#15372 (cleaning up sys.path handling), it's part of the current patch
for #16360 (wsgi entrypoint), and it's precisely that part of the latter
patch which I expect to modify once #15372 is fixed.
Once I'm done with that patch, I don't think the setup_settings function
will be needed anymore (as it's basically a wrapper around
setup_environ, which will be deprecated). Instead, I expect wsgi.py will
simply contain a line very similar to what is currently in manage.py,
"os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')".
This is much simpler and more explicit than setup_settings.
This still gives DJANGO_SETTINGS_MODULE priority, and just sets a
fallback value - I don't think we can change that in the default
manage.py or wsgi.py, without breaking the ability for people to
override using DJANGO_SETTINGS_MODULE if they want, which is the
established pattern. However, the advantage of it being explicit is that
you can easily change the behavior if you want. If you want the
environment variable ignored, you can change that line to
"os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'" in your
project, and then Django will always use "mysite.settings", regardless
of the environment variable's value.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYhIACgkQ8W4rlRKtE2d9xACglQHuQsuqk2DCUzWJVILTuv56
C84AoLRFUE4Z4hCwQxbGQa1VfUN5tdPh
=Y4O5
-END PGP SIGNATURE-
--
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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/11/2011 09:34 AM, Carl Meyer wrote:
> setup_environ, which will be deprecated). Instead, I expect wsgi.py will
> simply contain a line very similar to what is currently in manage.py,
> "os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'mysite.settings')".
I should say rather, "what is in the new manage.py in my #15372 patch",
not "what is currently in manage.py".
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UYr4ACgkQ8W4rlRKtE2ffDQCgubhrYgsp5u6pDmTfOnV1aVxg
KqUAn31gJXw8GxbvYOBASy6lqYpIsk42
=XPTp
-END PGP SIGNATURE-
--
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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Hanne, On 10/11/2011 06:31 AM, Hanne Moa wrote: > I already do it this way except the manage.py is vanilla. > > project-package/ > project.wsgi > requirements.txt > setup.py > .git > bin/ # virtualenv > ... > project/ > __init__.py > manage.py > settings.py > urls.py > ... I think many people are doing something similar to this - just taking the current startproject layout and wrapping it in an outer container directory. This solves problems 3 and (partly) 4, out of the five I listed. It means renaming the outermost directory no longer causes issues (#3), and it means that although you could have something adjacent to "project/" accidentally imported without seeming to be on sys.path, at least it'd be reliably reproduced because its a part of your repo, not outside it (thus partly #4). It doesn't do anything to solve 1, 2, or 5, because you still have the sys.path hack in setup_environ and you still have the doubled import paths, where you can import both "project.settings" and just "settings". Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6UY+AACgkQ8W4rlRKtE2f9bACfT5GLcOtz0RGWtMHhZYD0j2Zi zJwAn1z8qfxw3m6JXEPtwbQL+6JPnSzr =lnk9 -END PGP SIGNATURE- -- 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Aymeric,
On 10/11/2011 06:12 AM, Aymeric Augustin wrote:
> The new structure highlights that a Django project is:
> - an entrypoint for scripts manage.py — and soon another one for WSGI servers,
> - a settings module and a root URLconf, who happen to live in the same
> package by default,
> - some applications, templates, static files, etc.
>
> I was about to ask a question about the recommended project layout but
> I eventually found the answer here:
> https://github.com/carljm/django/commit/4ba999060d8c030dd43ef4a8ec2844850f0310b3#L2R380
>
> This information will still be interesting and useful long after the
> 1.4 release. Shouldn't we move it somewhere in the documentation and
> link to that page from the release notes?
Yes, I think adding a bit more detailed information about project layout
and Python path issues to the documentation makes sense.
> Also, following the Zen of Python, shouldn't we recommend the
> decoupled style (ie. put apps in the outer "mysite" directory)?
With my proposed patch we already implicitly recommend this by modeling
it in the tutorial, but we don't explain it particularly.
Personally I don't think it's as simple as a universal recommendation.
In practice I find that some apps are potentially destined for reuse,
and with those I prefer to start out with a top-level namespace. A few
(often those containing core content models) are inextricably tied to
the particular site/project, and for those I prefer to namespace them
inside the project namespace.
I'm not sure if that level of discussion belongs in the documentation or
not. I can try and see how it reads.
> Finally, if I understand correctly, the only reason why the default
> settings and URLconf are in a package ("mysite.settings" and
> "mysite.urls") is to avoid name conflicts. In particular, it makes it
> possible to run several Django projects in parallel with the same
> PYTHONPATH. It'd be worth mentioning this in the documentation, so
> that newcomers understand there's nothing magic with the name of the
> inner "mysite" directory.
Yeah - that's tricky to describe in the docs, since you still can't run
multiple Django projects in parallel *in a single process* (until we get
rid of settings as a process-global), but it does allow you to run
multiple projects in different processes using the same PYTHONPATH
setup. I can try to discuss this as well and see how it looks.
> I believe all this could go either in the tutorial or in a new page
> dedicated to project layout — the latter would allow us to give more
> details on the project layout options.
I think we should add a dedicated "Python path and project layout" page,
and link to it from the tutorial and elsewhere. This gets way too
complex to load onto beginners right away in the tutorial.
Carl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk6UetEACgkQ8W4rlRKtE2eTxgCfYbzpvkYU5BIY87U4QU5Ucf/A
dWUAmQFtfgluu0Ubf/RXaK9X+f3DD3sd
=4v8O
-END PGP SIGNATURE-
--
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: Cleaning up manage.py and import paths
> I think we should add a dedicated "Python path and project layout" page, > and link to it from the tutorial and elsewhere. This gets way too > complex to load onto beginners right away in the tutorial. > IIRC then this page has been proposed before and ultimately not been done because the rationale people presented was that, well, it depends... Howerver, I am thinking that even though it should remain as flexible as it is, maybe it would be nice to have some *recommendation* including a directory structure with a container dir (that's most likely a virtualenv, the result of mkvirtualenv) at it's root which then contains manage.py and mysite (or whatever one feeds to django-admin.py startproject ). example.com < the virtualenv, the outer container, result of mkvirtualenv example.com - manage.py - mysite/< result of django-admin.py startproject mysite from within example.com (after pip install django) -- 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/-/ptfTlEJEp78J. 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: Custom transform in django docs
Definitely in favor of removing it. I've run into that before and been frustrated by hacking around the strange indentation. - Gabriel -- 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/-/zdu_zw7iOVIJ. 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: Cleaning up manage.py and import paths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Markus, On 10/11/2011 11:50 AM, Markus Gattol wrote: > > I think we should add a dedicated "Python path and project layout" page, > and link to it from the tutorial and elsewhere. This gets way too > complex to load onto beginners right away in the tutorial. > > IIRC then this page has been proposed before and ultimately not been > done because the rationale people presented was that, well, it > depends... Yes, I think there's a lot of "it depends" involved. I'm envisioning a page that basically explains the default layout, why it works, why it's done that way, and briefly discusses what directions you can go with it. Nothing very extensive or highly prescriptive. After talking to Aymeric more on IRC, we agreed that this added docs page doesn't need to block the patch. The current documentation in the patch is adequate, this page would be an additional improvement. Which is good, because I'm not sure I have time to write that doc page right now :-) So I'm planning to commit the patch as-is and file a ticket for more docs with a link to this discussion. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAk6Ung0ACgkQ8W4rlRKtE2fb7gCVF3SD9aCilRUk6ieCN4Qs8wjW 2ACff+HtJSl1IE8iPNwPNVxMIl20D28= =PCjx -END PGP SIGNATURE- -- 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: Cleaning up manage.py and import paths
On Tue, Oct 11, 2011 at 3:50 PM, Carl Meyer wrote: > After talking to Aymeric more on IRC, we agreed that this added docs > page doesn't need to block the patch. The current documentation in the > patch is adequate, this page would be an additional improvement. Which > is good, because I'm not sure I have time to write that doc page right > now :-) So I'm planning to commit the patch as-is and file a ticket for > more docs with a link to this discussion. > +1 on the whole idea. One thing that I think should be added before commit is a note in the tutorial along the lines of "what if startproject didn't actually do what we are saying it did?" and explaining that the structure has recently changed and if you didn't get the structure described here than you are likely using an older version of the code than the documentation you are reading and you should get the two in sync. This was done back in the day of changing maxlength to max_length, and that note stayed in the tutorial a laughably long time after the change was no longer "recent", but it likely prevented lots of questions and duplicate bug reports about the tutorial being wrong. 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.
Re: Custom transform in django docs
On 10/10/11 17:30, Jacob Kaplan-Moss wrote: > Heh, so actually funny story. > > Turns out I copied this hack was over from the code I used for the > Django book. We did it there to surpress a difference between the HTML > conversion we used on the website and the OpenOffice conversion we > used for the print publication. So it's actually an artifact of our > hacked together book toolchain. I'm pretty surprised that it's still > there -- I'd totally forgotten about this hack. Ah, well that explains it! It's gone now :-) Luke -- "Oh, look. I appear to be lying at the bottom of a very deep, dark hole. That seems a familiar concept. What does it remind me of? Ah, I remember. Life." (Marvin the paranoid android) Luke Plant || http://lukeplant.me.uk/ -- 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.
Update on Ticket #16891: Delete/update should return number of rows modified
Finally got around to these simple changes: * https://github.com/estebistec/django/commit/b48a87afc324f5546b6654fa7638e406b397c0d6 * https://github.com/estebistec/django/commit/28ace32980b370fd17ae35019bfe8d055c673684 If the core devs approve of these changes I can get to work on creating the proper patch for SVN and add doc changes. Ticket: https://code.djangoproject.com/ticket/16891#comment:3 -- Steven -- 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.
