Re: Ability to migrate other applications

[Emmanuelle Delescolle]

I've been using this solution on a couple projects (including ones with 
several children to the same migration) and have never had troubles with 
the migration solver, I guess I have been lucky.

I'll throw a sample application today and try to reproduce the problem and 
see how it can be fixed/worked around. And write the appropriate tests.

Emma

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7a8629b7-4077-4818-b6b9-19725d4539e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

On Mon, Aug 24, 2015 at 9:32 PM, Ryan Hiebert  wrote:

>
> > On Aug 24, 2015, at 5:37 PM, Carl Meyer  wrote:
> >
> >> Any ideas on alternative ways to tackle this? I'm officially stuck.
> >
> > I'm afraid I don't have any solution to offer, other than embracing the
> > "abstract vs concrete" dependencies distinction, and accepting the fact
> > that users of your wheels/eggs are choosing to be more "on their own"
> > when it comes to their chosen dependency versions.
>
> I definitely agree. setup.py files, for the reason you mentioned, are not
> intended for concrete dependencies, while requirements.txt files are. They
> are the right tool for the job. If I was you, that's what I would do.


That sort of setup works fine when it's a standalone install on a server
that someone experienced with the Python world is maintaining, or a
developer working against a set of modules. It's not really an option for a
full-blown application meant to be easily installed by people used to being
able to run 'apt-get install ' or 'yum install '

As a more complex webapp, our packaging requires the
compilation/minification of .less/.js files, which means any user using the
sdist would need a suitable build environment. That raises a huge barrier
to installation for a significant chunk of our userbase. Our goal is to
keep installation simple for everyone, treating it much like any typical
application, without requiring a whole bunch of pre-setup. Aside from this
particular issue with the backported Django builds, we've been able to do
this for years.

It's basically the difference between being able to download/install a
setup.exe for OpenOffice as opposed to needing a build environment and
source to install it.

It's starting to sound like the best bet for us is to move away from
pip/easy_install for end-user consumption of the software and onto more of
a dedicated installer that can manage dependencies more explicitly, maybe
taking care of the building/consumption of a requirements.txt for them.

Thanks for your thoughts on this, everyone :)

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - https://www.reviewboard.org
Beanbag, Inc. - https://www.beanbaginc.com




>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/69fOquu8v-U/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/486DA079-7F97-4597-A7FB-CD179DFB54DC%40ryanhiebert.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbxkQaUW6HvLGrTpcZEyrAZGAvgidHHELHOK8-XgCje0zg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: community support of unmaintained versions of Django

[Ryan Hiebert]

> On Aug 24, 2015, at 5:37 PM, Carl Meyer  wrote:
> 
>> Any ideas on alternative ways to tackle this? I'm officially stuck.
> 
> I'm afraid I don't have any solution to offer, other than embracing the
> "abstract vs concrete" dependencies distinction, and accepting the fact
> that users of your wheels/eggs are choosing to be more "on their own"
> when it comes to their chosen dependency versions.

I definitely agree. setup.py files, for the reason you mentioned, are not 
intended for concrete dependencies, while requirements.txt files are. They are 
the right tool for the job. If I was you, that's what I would do.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/486DA079-7F97-4597-A7FB-CD179DFB54DC%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Re: Ability to migrate other applications

[Andrew Godwin]

The main problem I forsee here is just making sure that the MigrationLoader
knows to take these located-in-the-wrong-place migrations and insert them
into the migration tree right - in particular, you have issues with the
dependencies, because say you made a third-party migration that depends on
app_a.0003, and then they ship a new version that has app_a.0004, then
suddenly app_a.0003 has two different children and the migration solver is
going to really hate you.

Do you have a proposed workflow or tooling that would get around this?

Andrew

On Mon, Aug 24, 2015 at 10:54 AM, Emmanuelle Delescolle <
delesco...@gmail.com> wrote:

> Hi everyone,
>
> I'd like to talk about giving the ability to migrate models from other
> applications and I am addressing this mailing list as suggested by Tim
> Graham (https://code.djangoproject.com/ticket/25288).
>
> Although I think this might be dangerous if mis-used, this is not the
> first time I come across the need for migrating models from other apps.
>
> One simple use case is when using modeltranslations. When creating a
> translation.py in your own application to add multi-lingual capabilities to
> models from other (third party) apps, when running manage.py makemigations
> the migrations for those third-party apps will be created in the original
> app's directory which isn't (shouldn't be) part of your repository.
> Therefore, when deploying the project on another machine, the migrations
> will not be available (as the original third party app will probably be
> deployed from pypi) and the whole project will then crash.
> In this example, it is just a trivial case of running makemigrations on
> the server (which is not always possible depending on the deployment
> solution in use) but there are some more complex cases where the actual
> migration file is needed.
>
> Using MIGRATION_MODULES is not a suitable solutions as we still want to
> use the original app's other migrations and also keep the possibility to
> upgrade the said application.
>
> This is not the only use case, but it's probably one of the most frequent
> ones. Another use-case is when using contribute_to_class.
>
>
> A quite easy solution to these use-cases is to add (maybe with a warning)
> a "migrated_app" parameter to the Migration class. If this parameter is not
> None it will be used to determine the application the migration has to be
> applied to. If it is None, normal behavior is resumed with the app to which
> that migration belongs to.
>
> With this feature, manage.py makemigrations would still generate the
> migrations in the original thirs party app's directory, then the user would
> need to move and rename those newly generated files to their own (the
> user's) application (with appropriate dependencies). This isn't more
> complicated than creating a data migration.
> You can find mention of this feature here: ​
> http://stackoverflow.com/questions/24311993/how-to-add-a-new-field-to-a-model-with-new-django-migrations/27450550#27450550
> and you can find an implementation on
> https://github.com/nanuxbe/django/commit/30c6d5beadb7ae989f9b19d4c2f94c0ee2302519
> .
> The migration file would then be part of the project's repo and would be
> easily deployable
>
> I'm looking forward to your feedback.
>
> Thanks,
> Emma
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/d7f57adc-2669-4176-8ced-2bc63c4adac3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uoaaRhb4HHLjgMcSf5WUZsr%2BVBwgOJTPqE1xsjOtvGnKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Okay to use form field labels in admin history?

[Tim Graham]

Do you like the idea to use form field labels in the admin history messages 
instead of the form field names themselves?

It's been implemented here:
https://github.com/django/django/pull/5169

One consideration is that the messages are generated/stored in the current 
language so this could increase confusion in multilingual environments 
until this issue is addressed:
https://code.djangoproject.com/ticket/21113

I'm not sure if we should block the current pull request on that ticket or 
not.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/70deb271-2f0f-4f64-aa37-95dd82262c25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Josh Smeaton]

Expressions have built in support for ordering with asc or desc, see 
here: 
https://docs.djangoproject.com/en/1.8/ref/models/expressions/#django.db.models.Expression.asc

Meaning that -F() is never ambiguous, which is the main reason we went for 
the F().desc() API rather than using the minus sign as an indicator of 
ordering.

To use the `P` example in an order by statement:

Model.objects.order_by(P.related.date_field().desc())

I've "called" date_field here, but that's just assuming an API. As long as 
an expression is being returned, you can call `desc` on it.

What some other ORMs do is reference fields directly on the model, though 
I'm not sure I like the verboseness (but it gives you safety):

Model.objects.order_by(Model.related.date_field.desc())

The extra `Model` is annoying, but it does mean that you can actually look 
up fields as you go rather than just crafting an `F()` that is eventually 
resolved into the `Col()`. This would also allow us to return expressions 
directly. Not sure how or if this API would work with the current 
metaclasses though.

For what it's worth, the names `TreePath` and `FieldTree` are too low level 
for a public facing API that is supposed to make it easier/safer to craft 
field paths. One letter class names are also a bad design in general, so 
we'd need something half way between both if going for a new class.


On Tuesday, 25 August 2015 04:13:32 UTC+10, Alexey Zankevich wrote:
>
> Hey Josh,
>
> Here is the current state of F support by different functions:
>
> * annotations (Count, Sum etc) - work
> * order_by - works partially (only asc order supported)
> * select_related, prefetch_related - don't work
>
> So, F is not a universal interface for getting paths right now. Also, 
> there is another problem with F - it overloads python operators already, so 
> if we overload unary operation "-F", it will confuse users as in one case 
> it will return CombinedExpression (ex. 0-F('fieldname')), in the other - 
> OrderBy (ex. -F('fieldname')).
> Since F originally designed to describe arithmetic upon fields during 
> filtering, it will not be a perfect match to denote query paths.
> As for accepting callable as a query path factory, I don't think it's a 
> perfect match as well, as callable interface is too general, at least to be 
> an unnamed argument.
> For example, fields.CharField(default=callable) is a clear approach, as 
> it's obvious what was implied. 
> ModelClass.objects.all().order_by(callable) - still clear, but 
> YearGte(callable, 40) isn't (since I'm talking about general interface to 
> specify query paths in the whole project).
> So, I suggest a separate class for that purposes, and it doesn't 
> necessarily need to have short name like "P". Even better if it has 
> meaningful name like "TreePath" or "FieldTree".
>
>
> On Friday, August 21, 2015 at 4:26:34 AM UTC+3, Josh Smeaton wrote:
>
> Most expressions already support strings, and most that support strings 
> expect them to be field_paths that can be wrapped in F() expressions. So 
> you have two options really, without built in support from other 
> expressions.
>
> 1. P.field.other.some_field() returns an F()
> 2. P.field.other.some_field() returns a str that will be internally 
> wrapped in an F().
>
> The callable part of your syntax is just something I'm suggesting as an 
> option. The requirement is that a string or F() be returned in some way 
> though. I'm also using "P." as a stand-in as you used previously.
>
> Supporting callables is an interesting idea, and I don't think that'll 
> cause issues with existing expressions. The callable must return an 
> expression though. If you wanted to write a patch to support callables, I'd 
> be onboard to review ASAP.
>
> Cheers
>
> On Friday, 21 August 2015 00:16:45 UTC+10, Alexey Zankevich wrote:
>
> What about the idea to add interface to specify paths with special class 
> or callable?
>
>
> On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>
> If I finish the patch in time (I think I have about a month left), then 
> it'll be included in 1.9. Review and comments on the PR will go a long way 
> to helping me tidy it up sooner rather than later, so please feel free to 
> review.
>
> Regards,
>
> On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zankevich wrote:
>
> Once Josh completes this patch https://github.com/django/django/pull/5090
> (.filter method accepting class-based lookups and transforms), it will be
> almost everything required by third-party apps. Is it going to be a part of
> Django 1.9, by the way?
>
> Additionally, for pure flexibility, next method and classes need to accept
> either a callable or an object supporting special path interface (for 
> example,
> just a single method get_path() returning string path).
> They listed below:
>
> 1. The current methods.select_related, .prefetch_related, .order_by
> 2. Annotation classes Min, Max, Count, Sum
> 3. Future transforms and lookups classes
>
>
> 

Re: Pre-DEP: community support of unmaintained versions of Django

[Carl Meyer]

Hi Christian,

On 08/24/2015 03:52 PM, Christian Hammond wrote:
> pip's removed support for dependency_links, requiring that all package
> dependencies be made available on PyPI. This means there's no way we can
> host a build of this ourselves, have a project depend on it, and build
> the project as a package. It simply will ignore our builds and fail with
> a dependency error (assuming a version range of >=1.6.11.1,<1.7). (If
> installing from source, it looks like requirements.txt can still specify
> links, but that doesn't help when building/distributing wheels/eggs.)

Yes, I'm afraid you're trying to solve an additional problem I didn't
realize you had, because I didn't realize ReviewBoard was distributed as
wheels/eggs.

In general, my feeling has been that Python packaging is not well suited
to distributing deployable web apps, and they are better distributed as
source (with requirements.txt) plus installation instructions. I think
pip's developers feel similarly, and are aiming for a clear distinction
between setup.py "abstract" dependencies and requirements.txt "concrete"
ones. (See e.g. https://caremad.io/2013/07/setup-vs-requirement/,
authored by Donald Stufft, the primary pip maintainer.)

So the official line is that if you need to get _that_ specific about
dependency versions (and especially if you're needing to source those
versions off-PyPI), you should be distributing a requirements.txt file,
not a wheel or an egg.

Obviously there's nothing stopping you from doing that -- just have your
ReviewBoard setup.py depend on ``Django>=1.6,<1.7``, and then strongly
recommend to your clients that they have a ``requirements.txt`` file
with a ``--find-links`` line referencing your Django 1.6 unofficial
support downloads page in order to get the latest security-patched
versions. But that doesn't allow you to automatically enforce that all
the consumers of your wheels/eggs will actually do this.

[snip non-functional workaround]
> The only other option I can think of is to actually upload the 1.6.11.x
> build to PyPI under a different name ("beanbag-django16", for instance),
> but keep the top-level module as "django". This will inevitably cause
> conflicts with the officially installed Django package, though. Not a
> good option.

Nope, not great.

> So at this point, it seems that while we can maintain security backports
> of Django 1.6.11, we can't realistically depend on them or trigger
> upgrading to them. Short of the official Django package on PyPI either
> hosting our backports or registering URLs to them, there might not be a
> clean way to do this. I'm pretty sure is not the route you guys want to
> go for this, though.

I don't really think that's an option. At that point they'd have to be
officially supported, because there's no longer any opt-in required to
get them.

> Any ideas on alternative ways to tackle this? I'm officially stuck.

I'm afraid I don't have any solution to offer, other than embracing the
"abstract vs concrete" dependencies distinction, and accepting the fact
that users of your wheels/eggs are choosing to be more "on their own"
when it comes to their chosen dependency versions.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/55DB9CAA.3090108%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Pre-DEP: community support of unmaintained versions of Django

[Christian Hammond]

On Wed, Aug 19, 2015 at 4:43 PM, Markus Holtermann  wrote:

> Hey Christian,
>
> On Wed, Aug 19, 2015 at 02:41:49PM -0700, Christian Hammond wrote:
>
>> Regarding the version number, from what I've read, there's still a
>> reported
>> compatibility issue if we use the +localidentifer part of a version number
>> with older versions of setuptools. I need to do some testing on this. If I
>> don't hit any issues, I'm very happy to put an identifier on there. I
>> would
>> like to keep it at 1.6.11.x, rather than 1.6.12+, so that it's very clear
>> we're based on upstream Django 1.6.11.
>>
>
> Thanks, that sounds good to me. 1.6.11.x+unofficial if possible,
> otherwise 1.6.11.x


Looks like it's going to have to be 1.6.11.x.

However, I've hit a pretty major stumbling block here.

pip's removed support for dependency_links, requiring that all package
dependencies be made available on PyPI. This means there's no way we can
host a build of this ourselves, have a project depend on it, and build the
project as a package. It simply will ignore our builds and fail with a
dependency error (assuming a version range of >=1.6.11.1,<1.7). (If
installing from source, it looks like requirements.txt can still specify
links, but that doesn't help when building/distributing wheels/eggs.)

I tried a hacky workaround of creating a sdist package that invoked
setuptools to install using dependency_links, and depended on that package
instead. Older versions of pip prior to 7.0 would execute our setup.py and
in turn install our build of Django. However, since pip now converts sdists
to wheels prior to installing, it just skips over dependency_links,
resulting in the original problem.

The only other option I can think of is to actually upload the 1.6.11.x
build to PyPI under a different name ("beanbag-django16", for instance),
but keep the top-level module as "django". This will inevitably cause
conflicts with the officially installed Django package, though. Not a good
option.

So at this point, it seems that while we can maintain security backports of
Django 1.6.11, we can't realistically depend on them or trigger upgrading
to them. Short of the official Django package on PyPI either hosting our
backports or registering URLs to them, there might not be a clean way to do
this. I'm pretty sure is not the route you guys want to go for this, though.

Any ideas on alternative ways to tackle this? I'm officially stuck.

Christian

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHfcSbx9nwya7Aw3rnmECBZjE%3DwGW%2BSgzMT1tYo9xfXQgiHYjw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: templates block prepend and append

[Shai Berger]

Hi and all,

On Monday 24 August 2015 23:37:57 Collin Anderson wrote:
> On Mon, Aug 24, 2015 at 2:25 AM, Amin Jun 
> 
> wrote:
> > I liked his suggestion, I don't know if I'm using template tags
> > correctly, but I'm writing a template tag {% load_comment
> > comment_manager %} , "load_comment" renders a file "comments.html" and
> > also needs a file "comment.js" and in any page that has comments, I have
> > to add "comment.js" manually to my {% block js %}.
> > it was better if i could put something like this in my "comments.html"
> > file
> > 
> > {% append_block js %}
> > < script src="..." >
> > {% end_append_block %}
> > 
> 
> I think this might do what you want:
> 
> {% block js %}{{ block.super }}  {% endblock %}
> 

I think it does not -- this, as he complained, needs to be put manually in 
every page which uses his {% load_comment %} tag; IIUC, he's asking for a way 
for his tag to do that for him.

I'm not sure that such a mechanism is feasible or even sensible within DTL, 
but it's a valid issue for this list, unless I'm missing something.

Shai.

Re: templates block prepend and append

[Collin Anderson]

Hi Jun,

I think this might do what you want:

{% block js %}{{ block.super }}  {% endblock %}

But, like the original poster said, please use django-users list for things
like this.

Thanks,
Collin


On Mon, Aug 24, 2015 at 2:25 AM, Amin Jun 
wrote:

> I liked his suggestion, I don't know if I'm using template tags correctly,
> but I'm writing a template tag {% load_comment comment_manager %} ,
> "load_comment" renders a file "comments.html" and also needs a file
> "comment.js" and in any page that has comments, I have to add "comment.js"
> manually to my {% block js %}.
> it was better if i could put something like this in my "comments.html"
> file
>
> {% append_block js %}
> < script src="..." >
> {% end_append_block %}
>
> Best regards
>
> Jun
>
> On Friday, May 20, 2011 at 9:20:22 PM UTC+4:30, Matt wrote:
>>
>> This should solve my problems, therefore my question is no longer valid.
>>
>> I missed that in the documentation.
>>
>> Probably I should ask at django-users first.
>>
>> Although
>>
>> {% extends "admin/index.html" after "blockname" %}
>>
>> would be a nice shorthand.
>>
>> or
>>
>> {% from "admin/index.html" import "blockname" %}
>>
>> to import only one block from a template file.
>>
>> --
>> Matt Harasymczuk
>> http://www.matt.harasymczuk.pl
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3e77b96d-c187-406a-8d08-140958dac251%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S4TiAeuvdiJyTFK9Cz8h%2B98L68fVnWEjdk912zLymqqWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

status of 1.9 release blockers

[Tim Graham]

Time to kickoff the progress tracker for the next major release!

Here's the status with 4 weeks to go until alpha (September 21).

Release blockers:

- Add Oracle support for new-style GIS functions
https://code.djangoproject.com/ticket/24688
Owner: Jani Tiainen
Status: In progress (test suite runs on Oracle now, which is an improvement 
from last week)


Other tickets tagged for 1.9:

- No way to create tables for apps without migrations
https://code.djangoproject.com/ticket/25144
Status: Awaiting replies to "Keeping apps without migrations?" thread for a 
decision on what to do
Mailing list thread: 
https://groups.google.com/d/topic/django-developers/qHP4ZQSK9xM/discussion
Owner: pending discussion

- Replace admin icons images by inline SVG
https://code.djangoproject.com/ticket/20597
Owner: elky
Status: In progress

- Update tutorial screenshots for new admin theme
https://code.djangoproject.com/ticket/25200
Status: to be done after previous item is completed


Relevant ticket filters:

Release blockers affecting master:
https://code.djangoproject.com/query?status=assigned=new=master=Release+blocker

Tickets tagged 1.9:
https://code.djangoproject.com/query?status=assigned=new=~1.9

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/15078a94-d67e-4105-a739-d02c8a42ebfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django ORM query syntax enhancement

[Alexey Zankevich]

Hey Josh,

Here is the current state of F support by different functions:

* annotations (Count, Sum etc) - work
* order_by - works partially (only asc order supported)
* select_related, prefetch_related - don't work

So, F is not a universal interface for getting paths right now. Also, there 
is another problem with F - it overloads python operators already, so if we 
overload unary operation "-F", it will confuse users as in one case it will 
return CombinedExpression (ex. 0-F('fieldname')), in the other - OrderBy 
(ex. -F('fieldname')).
Since F originally designed to describe arithmetic upon fields during 
filtering, it will not be a perfect match to denote query paths.
As for accepting callable as a query path factory, I don't think it's a 
perfect match as well, as callable interface is too general, at least to be 
an unnamed argument.
For example, fields.CharField(default=callable) is a clear approach, as 
it's obvious what was implied. 
ModelClass.objects.all().order_by(callable) - still clear, but 
YearGte(callable, 40) isn't (since I'm talking about general interface to 
specify query paths in the whole project).
So, I suggest a separate class for that purposes, and it doesn't 
necessarily need to have short name like "P". Even better if it has 
meaningful name like "TreePath" or "FieldTree".


On Friday, August 21, 2015 at 4:26:34 AM UTC+3, Josh Smeaton wrote:
>
> Most expressions already support strings, and most that support strings 
> expect them to be field_paths that can be wrapped in F() expressions. So 
> you have two options really, without built in support from other 
> expressions.
>
> 1. P.field.other.some_field() returns an F()
> 2. P.field.other.some_field() returns a str that will be internally 
> wrapped in an F().
>
> The callable part of your syntax is just something I'm suggesting as an 
> option. The requirement is that a string or F() be returned in some way 
> though. I'm also using "P." as a stand-in as you used previously.
>
> Supporting callables is an interesting idea, and I don't think that'll 
> cause issues with existing expressions. The callable must return an 
> expression though. If you wanted to write a patch to support callables, I'd 
> be onboard to review ASAP.
>
> Cheers
>
> On Friday, 21 August 2015 00:16:45 UTC+10, Alexey Zankevich wrote:
>
> What about the idea to add interface to specify paths with special class 
> or callable?
>
>
> On Wednesday, August 19, 2015 at 10:49:07 AM UTC+3, Josh Smeaton wrote:
>
> If I finish the patch in time (I think I have about a month left), then 
> it'll be included in 1.9. Review and comments on the PR will go a long way 
> to helping me tidy it up sooner rather than later, so please feel free to 
> review.
>
> Regards,
>
> On Wednesday, 19 August 2015 04:55:21 UTC+10, Alexey Zankevich wrote:
>
> Once Josh completes this patch https://github.com/django/django/pull/5090
> (.filter method accepting class-based lookups and transforms), it will be
> almost everything required by third-party apps. Is it going to be a part of
> Django 1.9, by the way?
>
> Additionally, for pure flexibility, next method and classes need to accept
> either a callable or an object supporting special path interface (for 
> example,
> just a single method get_path() returning string path).
> They listed below:
>
> 1. The current methods.select_related, .prefetch_related, .order_by
> 2. Annotation classes Min, Max, Count, Sum
> 3. Future transforms and lookups classes
>
>
> Examples:
>
> >>> path = lambda x: 'user__last_login_date'
> >>> GameSession.objects.all().order_by(path)
>
> or
>
> >>> class LoginDatePath(object):
> ... def get_path(self):
> ... return 'user__last_login_date'
> >>> path = LoginDatePath()
> >>> GameSession.objects.all().order_by(path)
>
> Path generation is a critical part of external query syntax as it used in
> almost all aspects of the ORM, meanwhile each related method accepts 
> either a
> string or (in some cases) a specific kind of class - OrderBy for order_by
> method, Prefetch for prefetch_related and etc.
>
>
> On Tuesday, August 18, 2015 at 7:54:48 PM UTC+3, Michael Manfre wrote:
>
> +1 for making it doable for 3rd party apps.
>
> Regards,
> Michael Manfre
>
> On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen  
> wrote:
>
> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> different querying syntax, and then lets see which solution (if any)
> gets popular enough to be integrated into Django.
>
>  - Anssi
>
>
>
> On Tue, Aug 18, 2015 at 5:54 PM, Collin Anderson  
> wrote:
> > Just a quick thought: I could imagine some newbies could get confused by 
> the
> > python-like syntax and try to do:
> >
> > Equal(P.user.get_full_name(), 'Bob Someone')
> >
> > I don't think it's not a huge deal, but worth noting.
> >
> > On Tuesday, August 18, 2015 at 8:00:17 AM UTC-4, Alexey Zankevich 

Re: Improving MSSQL and Azure SQL support on Django

[Tim Graham]

I guess the first step is to identify which third-party backend(s) we'll 
target to adopt officially (or at least borrow from heavily). For example, 
will we need separate backends for MSSQL and Azure? (Knowing nothing about 
the landscape myself, this question could be nonsensical.) Is this 
discussion something that should happen before the October summit? It seems 
to me the face-to-face time will likely be more productive if we have some 
of the high-level details ironed out.

By the way, is videoconferencing an option for Django developers interested 
in participating in the discussion at that time but unable to travel to 
Seattle?

On Saturday, August 22, 2015 at 5:53:37 PM UTC-4, Shai Berger wrote:
>
> On Saturday 22 August 2015 13:28:31 Aymeric Augustin wrote:
>
> > 
>
> > There isn’t such a clear story for running Django on Linux. This led me 
> to
>
> > write https://github.com/aaugustin/django-pymssql. Alternatives include
>
> > https://github.com/denisenkom/django-sqlserver and
>
> > https://github.com/lionheart/django-pyodbc.
>
>  
>
> There's also django-pyodbc-azure 
> , a fork of 
> django-pyodbc (actually, the current django-pyodbc is also a fork of the 
> original project, which has been discontinued). I took the liberty to 
> forward the message to that project.
>
>  
>
> Shai.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/30801c84-3e86-4ace-97e2-dde074169593%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ability to migrate other applications

[Emmanuelle Delescolle]

Hi everyone,

I'd like to talk about giving the ability to migrate models from other 
applications and I am addressing this mailing list as suggested by Tim 
Graham (https://code.djangoproject.com/ticket/25288).

Although I think this might be dangerous if mis-used, this is not the first 
time I come across the need for migrating models from other apps.

One simple use case is when using modeltranslations. When creating a 
translation.py in your own application to add multi-lingual capabilities to 
models from other (third party) apps, when running manage.py makemigations 
the migrations for those third-party apps will be created in the original 
app's directory which isn't (shouldn't be) part of your repository.
Therefore, when deploying the project on another machine, the migrations 
will not be available (as the original third party app will probably be 
deployed from pypi) and the whole project will then crash.
In this example, it is just a trivial case of running makemigrations on the 
server (which is not always possible depending on the deployment solution 
in use) but there are some more complex cases where the actual migration 
file is needed.

Using MIGRATION_MODULES is not a suitable solutions as we still want to use 
the original app's other migrations and also keep the possibility to 
upgrade the said application.

This is not the only use case, but it's probably one of the most frequent 
ones. Another use-case is when using contribute_to_class.


A quite easy solution to these use-cases is to add (maybe with a warning) a 
"migrated_app" parameter to the Migration class. If this parameter is not 
None it will be used to determine the application the migration has to be 
applied to. If it is None, normal behavior is resumed with the app to which 
that migration belongs to.

With this feature, manage.py makemigrations would still generate the 
migrations in the original thirs party app's directory, then the user would 
need to move and rename those newly generated files to their own (the 
user's) application (with appropriate dependencies). This isn't more 
complicated than creating a data migration.
You can find mention of this feature here: 
​http://stackoverflow.com/questions/24311993/how-to-add-a-new-field-to-a-model-with-new-django-migrations/27450550#27450550
 
and you can find an implementation 
on 
https://github.com/nanuxbe/django/commit/30c6d5beadb7ae989f9b19d4c2f94c0ee2302519
 
.
The migration file would then be part of the project's repo and would be 
easily deployable

I'm looking forward to your feedback.

Thanks,
Emma

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d7f57adc-2669-4176-8ced-2bc63c4adac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: templates block prepend and append

[Amin Jun]

I liked his suggestion, I don't know if I'm using template tags correctly, 
but I'm writing a template tag {% load_comment comment_manager %} , 
"load_comment" renders a file "comments.html" and also needs a file 
"comment.js" and in any page that has comments, I have to add "comment.js" 
manually to my {% block js %}. 
it was better if i could put something like this in my "comments.html" file 

{% append_block js %}
< script src="..." >
{% end_append_block %}
 
Best regards

Jun

On Friday, May 20, 2011 at 9:20:22 PM UTC+4:30, Matt wrote:
>
> This should solve my problems, therefore my question is no longer valid.
>
> I missed that in the documentation.
>
> Probably I should ask at django-users first.
>
> Although
>
> {% extends "admin/index.html" after "blockname" %}
>
> would be a nice shorthand.
>
> or 
>
> {% from "admin/index.html" import "blockname" %}
>
> to import only one block from a template file.
>
> --
> Matt Harasymczuk
> http://www.matt.harasymczuk.pl
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3e77b96d-c187-406a-8d08-140958dac251%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: URL dispatcher API

[Tim Graham]

You would have to take a look at the pull request and figure out the 
status. As far as I know, there aren't any status updates elsewhere.

On Monday, August 24, 2015 at 11:52:49 AM UTC-4, James Addison wrote:
>
> Assuming 
> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
>  
> is the canonical source for the project details, what is the status of each 
> of its goals? From a high level, the project seems well described on that 
> page, but everything after (ie. status) seems opaque - unless there is 
> another resource?
>
> It would be a shame for something so powerful to fall by the wayside. I'm 
> sure I'm not the only one to see such value in this addition.
>
> On Monday, August 24, 2015 at 10:36:53 AM UTC-4, Tim Graham wrote:
>>
>> I don't think so. Marten has been MIA unfortunately. Someone else could 
>> try to pick it up, but it seems a bit ambitious to complete in the time 
>> remaining before alpha.
>>
>> On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote:
>>>
>>> Hi Marten,
>>>
>>> I'm just curious if this is still on track for inclusion within the Sept 
>>> 21 Apha feature deadline? I've been using your Django `dispatcher_api` 
>>> branch for a new project since I learned of your proposed changes and am 
>>> excited to see them in stable Django. There hasn't been any changes in 
>>> about a month on your branch, so I'm (hopefully understandably) curious as 
>>> to its future?
>>>
>>> Cheers,
>>> James
>>>
>>> On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:

 Hi James,

 Thanks for taking a look at this, I really appreciate it. 

 *Major bug:* the `request` object needs to be passed into `resolve()` 
> here: 
> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>  
> - otherwise host and scheme constraints cannot work. I believe there are 
> other instances of `resolve()` not getting `request`, but mostly in 
> tests. 
> Is there a way for `request` to be a required parameter instead of 
> defaulting to `None`?
>

 Damn... I'll fix this asap. I haven't implemented any request-based 
 constraints yet, which allowed this to slip through without any test 
 failures. I'm afraid I can't just make `request` a required parameter, as 
 it needs to maintain backwards compatibility. With that said, the current 
 function signature of `resolve()` is just... awkward. One option is to 
 change it to `resolve(request_or_path, urlconf=None)`, and get the 
 path_info from the request if a request is supplied. `resolve()` might 
 still be called in a context where there is not request available, so I 
 think we need to maintain the ability to resolve just the path. 
  

> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
> going to a url using the 'localhost:8000' subdomain that only exists 
> on the 'my' subdomain (ie. http://my.example.com/test3/ exists, but 
> you try to go to http://localhost:8000/test3/), the debug mode 
> 'patterns tried list' is a series of blank lines. See image below:
>

 I would've expected at least the regexes here. I'll look into this. 

 *​Nice to have:* When attempting to use multiple constraints (ie. list 
> or tuple of constraints), using `RegexPattern` seems to be required 
> when doing pattern matching - otherwise it messes up while calling 
> `construct`. First glance says this is by design? I think it would be 
> nice 
> to still be able to use the old r'' (without wrapping in 
> `RegexPattern`) syntax as well. Not critical, as the multi-constraints is 
> NOT breaking behaviour, just new.
>

 Yes, this is more or less by design. While in the case of a single 
 constraint it's nice and concise. Once you use a list of constraints 
 you'll 
 have to start counting brackets to see if that string is a RegexPattern or 
 a parameter to another constraint, or you'll put each constraint on a new 
 line and it doesn't matter as much imo. It isn't set in stone, so if you 
 have any compelling arguments to change this, let me know. 
  

> *Nice to have:* I realise this isn't likely to happen at all, but it 
> would be nice if when `reverse()` and `{% url %}` are called, it would be 
> good to be able to automatically drop the scheme and host when 
> reconstituting an absolute URL if the scheme and host of the current 
> request match.  However, I'm pretty sure that this is not possible, given 
> the various scenarios in which these methods can be called. Obviously, 
> this 
> is not required, as the resulting URL (with scheme/host or without when 
> matching) will still work regardless!
>

 I'll probably implement something like this before it is merged. I've 
 

Re: URL dispatcher API

[James Addison]

Assuming 
https://www.google-melange.com/gsoc/project/details/google/gsoc2015/knbk/5668600916475904
 
is the canonical source for the project details, what is the status of each 
of its goals? From a high level, the project seems well described on that 
page, but everything after (ie. status) seems opaque - unless there is 
another resource?

It would be a shame for something so powerful to fall by the wayside. I'm 
sure I'm not the only one to see such value in this addition.

On Monday, August 24, 2015 at 10:36:53 AM UTC-4, Tim Graham wrote:
>
> I don't think so. Marten has been MIA unfortunately. Someone else could 
> try to pick it up, but it seems a bit ambitious to complete in the time 
> remaining before alpha.
>
> On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote:
>>
>> Hi Marten,
>>
>> I'm just curious if this is still on track for inclusion within the Sept 
>> 21 Apha feature deadline? I've been using your Django `dispatcher_api` 
>> branch for a new project since I learned of your proposed changes and am 
>> excited to see them in stable Django. There hasn't been any changes in 
>> about a month on your branch, so I'm (hopefully understandably) curious as 
>> to its future?
>>
>> Cheers,
>> James
>>
>> On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:
>>>
>>> Hi James,
>>>
>>> Thanks for taking a look at this, I really appreciate it. 
>>>
>>> *Major bug:* the `request` object needs to be passed into `resolve()` 
 here: 
 https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
  
 - otherwise host and scheme constraints cannot work. I believe there are 
 other instances of `resolve()` not getting `request`, but mostly in tests. 
 Is there a way for `request` to be a required parameter instead of 
 defaulting to `None`?

>>>
>>> Damn... I'll fix this asap. I haven't implemented any request-based 
>>> constraints yet, which allowed this to slip through without any test 
>>> failures. I'm afraid I can't just make `request` a required parameter, as 
>>> it needs to maintain backwards compatibility. With that said, the current 
>>> function signature of `resolve()` is just... awkward. One option is to 
>>> change it to `resolve(request_or_path, urlconf=None)`, and get the 
>>> path_info from the request if a request is supplied. `resolve()` might 
>>> still be called in a context where there is not request available, so I 
>>> think we need to maintain the ability to resolve just the path. 
>>>  
>>>
 *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
 going to a url using the 'localhost:8000' subdomain that only exists 
 on the 'my' subdomain (ie. http://my.example.com/test3/ exists, but 
 you try to go to http://localhost:8000/test3/), the debug mode 
 'patterns tried list' is a series of blank lines. See image below:

>>>
>>> I would've expected at least the regexes here. I'll look into this. 
>>>
>>> *​Nice to have:* When attempting to use multiple constraints (ie. list 
 or tuple of constraints), using `RegexPattern` seems to be required 
 when doing pattern matching - otherwise it messes up while calling 
 `construct`. First glance says this is by design? I think it would be nice 
 to still be able to use the old r'' (without wrapping in 
 `RegexPattern`) syntax as well. Not critical, as the multi-constraints is 
 NOT breaking behaviour, just new.

>>>
>>> Yes, this is more or less by design. While in the case of a single 
>>> constraint it's nice and concise. Once you use a list of constraints you'll 
>>> have to start counting brackets to see if that string is a RegexPattern or 
>>> a parameter to another constraint, or you'll put each constraint on a new 
>>> line and it doesn't matter as much imo. It isn't set in stone, so if you 
>>> have any compelling arguments to change this, let me know. 
>>>  
>>>
 *Nice to have:* I realise this isn't likely to happen at all, but it 
 would be nice if when `reverse()` and `{% url %}` are called, it would be 
 good to be able to automatically drop the scheme and host when 
 reconstituting an absolute URL if the scheme and host of the current 
 request match.  However, I'm pretty sure that this is not possible, given 
 the various scenarios in which these methods can be called. Obviously, 
 this 
 is not required, as the resulting URL (with scheme/host or without when 
 matching) will still work regardless!

>>>
>>> I'll probably implement something like this before it is merged. I've 
>>> been struggling to implement the `URL` class in a way that provided such 
>>> methods in a way that fully conformed RFC 3986, but it was taking up too 
>>> much of my time and I dropped it for now. I'm not sure I'll get it to 
>>> conform to RFC 3986, but I'll surely write some basic implementation to 
>>> output urls relative to the 

Re: URL dispatcher API

[Tim Graham]

I don't think so. Marten has been MIA unfortunately. Someone else could try 
to pick it up, but it seems a bit ambitious to complete in the time 
remaining before alpha.

On Monday, August 24, 2015 at 10:02:38 AM UTC-4, James Addison wrote:
>
> Hi Marten,
>
> I'm just curious if this is still on track for inclusion within the Sept 
> 21 Apha feature deadline? I've been using your Django `dispatcher_api` 
> branch for a new project since I learned of your proposed changes and am 
> excited to see them in stable Django. There hasn't been any changes in 
> about a month on your branch, so I'm (hopefully understandably) curious as 
> to its future?
>
> Cheers,
> James
>
> On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:
>>
>> Hi James,
>>
>> Thanks for taking a look at this, I really appreciate it. 
>>
>> *Major bug:* the `request` object needs to be passed into `resolve()` 
>>> here: 
>>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>>>  
>>> - otherwise host and scheme constraints cannot work. I believe there are 
>>> other instances of `resolve()` not getting `request`, but mostly in tests. 
>>> Is there a way for `request` to be a required parameter instead of 
>>> defaulting to `None`?
>>>
>>
>> Damn... I'll fix this asap. I haven't implemented any request-based 
>> constraints yet, which allowed this to slip through without any test 
>> failures. I'm afraid I can't just make `request` a required parameter, as 
>> it needs to maintain backwards compatibility. With that said, the current 
>> function signature of `resolve()` is just... awkward. One option is to 
>> change it to `resolve(request_or_path, urlconf=None)`, and get the 
>> path_info from the request if a request is supplied. `resolve()` might 
>> still be called in a context where there is not request available, so I 
>> think we need to maintain the ability to resolve just the path. 
>>  
>>
>>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
>>> going to a url using the 'localhost:8000' subdomain that only exists on 
>>> the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you 
>>> try to go to http://localhost:8000/test3/), the debug mode 'patterns 
>>> tried list' is a series of blank lines. See image below:
>>>
>>
>> I would've expected at least the regexes here. I'll look into this. 
>>
>> *​Nice to have:* When attempting to use multiple constraints (ie. list 
>>> or tuple of constraints), using `RegexPattern` seems to be required 
>>> when doing pattern matching - otherwise it messes up while calling 
>>> `construct`. First glance says this is by design? I think it would be nice 
>>> to still be able to use the old r'' (without wrapping in 
>>> `RegexPattern`) syntax as well. Not critical, as the multi-constraints is 
>>> NOT breaking behaviour, just new.
>>>
>>
>> Yes, this is more or less by design. While in the case of a single 
>> constraint it's nice and concise. Once you use a list of constraints you'll 
>> have to start counting brackets to see if that string is a RegexPattern or 
>> a parameter to another constraint, or you'll put each constraint on a new 
>> line and it doesn't matter as much imo. It isn't set in stone, so if you 
>> have any compelling arguments to change this, let me know. 
>>  
>>
>>> *Nice to have:* I realise this isn't likely to happen at all, but it 
>>> would be nice if when `reverse()` and `{% url %}` are called, it would be 
>>> good to be able to automatically drop the scheme and host when 
>>> reconstituting an absolute URL if the scheme and host of the current 
>>> request match.  However, I'm pretty sure that this is not possible, given 
>>> the various scenarios in which these methods can be called. Obviously, this 
>>> is not required, as the resulting URL (with scheme/host or without when 
>>> matching) will still work regardless!
>>>
>>
>> I'll probably implement something like this before it is merged. I've 
>> been struggling to implement the `URL` class in a way that provided such 
>> methods in a way that fully conformed RFC 3986, but it was taking up too 
>> much of my time and I dropped it for now. I'm not sure I'll get it to 
>> conform to RFC 3986, but I'll surely write some basic implementation to 
>> output urls relative to the current host and scheme. Of course it won't 
>> cover 100% of the cases as the "current" host and scheme are not always 
>> available, but in the basic cases it should be doable. 
>>
>> Op vrijdag 10 juli 2015 15:21:36 UTC+2 schreef Tim Graham:
>>>
>>> Marten, did you consider putting the new API in `django.urls` instead of 
>>> `django.core.urls`? I don't need there's a need to namespace it under 
>>> "core", but others might be able to confirm the philosophy behind this.
>>>
>>
>> That's certainly worth considering, in fact, I quite like the idea. If 
>> there are no objections (philosophical or otherwise) I'll move it to 
>> `django.urls`. 

Re: URL dispatcher API

[James Addison]

Hi Marten,

I'm just curious if this is still on track for inclusion within the Sept 21 
Apha feature deadline? I've been using your Django `dispatcher_api` branch 
for a new project since I learned of your proposed changes and am excited 
to see them in stable Django. There hasn't been any changes in about a 
month on your branch, so I'm (hopefully understandably) curious as to its 
future?

Cheers,
James

On Friday, July 10, 2015 at 4:55:22 PM UTC-4, Marten Kenbeek wrote:
>
> Hi James,
>
> Thanks for taking a look at this, I really appreciate it. 
>
> *Major bug:* the `request` object needs to be passed into `resolve()` 
>> here: 
>> https://github.com/knbk/django/blob/4a9d2a05bb76c9ad996921b9efadd8dad877540e/django/core/handlers/base.py#L134
>>  
>> - otherwise host and scheme constraints cannot work. I believe there are 
>> other instances of `resolve()` not getting `request`, but mostly in tests. 
>> Is there a way for `request` to be a required parameter instead of 
>> defaulting to `None`?
>>
>
> Damn... I'll fix this asap. I haven't implemented any request-based 
> constraints yet, which allowed this to slip through without any test 
> failures. I'm afraid I can't just make `request` a required parameter, as 
> it needs to maintain backwards compatibility. With that said, the current 
> function signature of `resolve()` is just... awkward. One option is to 
> change it to `resolve(request_or_path, urlconf=None)`, and get the 
> path_info from the request if a request is supplied. `resolve()` might 
> still be called in a context where there is not request available, so I 
> think we need to maintain the ability to resolve just the path. 
>  
>
>> *Minor bug:* Given two subdomains, my.example.com and localhost:8000, 
>> going to a url using the 'localhost:8000' subdomain that only exists on 
>> the 'my' subdomain (ie. http://my.example.com/test3/ exists, but you try 
>> to go to http://localhost:8000/test3/), the debug mode 'patterns tried 
>> list' is a series of blank lines. See image below:
>>
>
> I would've expected at least the regexes here. I'll look into this. 
>
> *​Nice to have:* When attempting to use multiple constraints (ie. list or 
>> tuple of constraints), using `RegexPattern` seems to be required when 
>> doing pattern matching - otherwise it messes up while calling `construct`. 
>> First glance says this is by design? I think it would be nice to still be 
>> able to use the old r'' (without wrapping in `RegexPattern`) 
>> syntax as well. Not critical, as the multi-constraints is NOT breaking 
>> behaviour, just new.
>>
>
> Yes, this is more or less by design. While in the case of a single 
> constraint it's nice and concise. Once you use a list of constraints you'll 
> have to start counting brackets to see if that string is a RegexPattern or 
> a parameter to another constraint, or you'll put each constraint on a new 
> line and it doesn't matter as much imo. It isn't set in stone, so if you 
> have any compelling arguments to change this, let me know. 
>  
>
>> *Nice to have:* I realise this isn't likely to happen at all, but it 
>> would be nice if when `reverse()` and `{% url %}` are called, it would be 
>> good to be able to automatically drop the scheme and host when 
>> reconstituting an absolute URL if the scheme and host of the current 
>> request match.  However, I'm pretty sure that this is not possible, given 
>> the various scenarios in which these methods can be called. Obviously, this 
>> is not required, as the resulting URL (with scheme/host or without when 
>> matching) will still work regardless!
>>
>
> I'll probably implement something like this before it is merged. I've been 
> struggling to implement the `URL` class in a way that provided such methods 
> in a way that fully conformed RFC 3986, but it was taking up too much of my 
> time and I dropped it for now. I'm not sure I'll get it to conform to RFC 
> 3986, but I'll surely write some basic implementation to output urls 
> relative to the current host and scheme. Of course it won't cover 100% of 
> the cases as the "current" host and scheme are not always available, but in 
> the basic cases it should be doable. 
>
> Op vrijdag 10 juli 2015 15:21:36 UTC+2 schreef Tim Graham:
>>
>> Marten, did you consider putting the new API in `django.urls` instead of 
>> `django.core.urls`? I don't need there's a need to namespace it under 
>> "core", but others might be able to confirm the philosophy behind this.
>>
>
> That's certainly worth considering, in fact, I quite like the idea. If 
> there are no objections (philosophical or otherwise) I'll move it to 
> `django.urls`. 
>
> Marten
>

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

Re: A new setting for custom gettext domains?

[Krzysio Gutkowski]

Hi,

It looks that implementing it in that ways makes more sense.

However, if I were to implement it in that way, should I change both settings 
in one PR, or should I rework the LOCALE_PATHS setting in a separate PR?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dde81d01-8ff9-4081-a575-72adb89dcf5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: request for API review of streaming responses additions

[Tom Christie]

Potential there to treat these as separately reviewable pull requests.

For example - needing streaming template generation doesn't *necessarily* 
imply needing streaming responses. The node-by-node rendering might mean 
imply that less memory is used during the template rendering, even if the 
complete response content all ends up in memory. (I haven't got a handle 
from the pull request on if that'd be the case or not, and it's possible 
that I've misrepresented it, and there's no benefit other than being able 
to stream the output bytes)

More generally: As presented there's lots of technical change, with very 
little simple end-user presentable "why and when this is a benefit?".

* Template.stream()

What's the data to back this up?
Does this result in lower memory usage during the template generation, or 
is there no difference aside from allowing the output to be streamed? If 
there is an internal benefit then how large do those templates need to be 
before that's significant?

* StreamingTemplateResponse

Again, where's the data to back this up? We're introducing a decision point 
for our users without giving them any basis on which to make that decision. 
At what point would I likely want to use this, and what real-world cases 
for our users are driving this? (For really large CSV responses are 
templates a good idea in any case?)

I also don't really understand from the documentation how the behavior for 
SimpleStreamingTemplateResponse and StreamingTemplateResponse differs - 
"does not handle any rendering attributes/methods (including callbacks)" - 
I understand what the callbacks refer to there, but what does the rest of 
that mean?

* django.views.generic.base.StreamingTemplateView

Unclear to me that the decision point this view introduces to users is 
worth the benefit it provides.
Writing a view that streams a simple template is just about as simple a 
view as is possible to write in Django - would it be better if we simply 
took an informed decision on which of TemplateView / StreamingTemplateView 
is likely to be a better default on behalf of our users?

Also lukewarm on introducing a new GCBV that actually just requires a 
one-line addition to an existing GCBV. Should we prefer to instead document 
the usage of `response_class` more fully, rather than extending the API 
surface area?

Apologies for jumping in with the criticisms - intended positively! 
Understand the intent behind this, but a bit wary of changes that come 
across as purely technical with very little in the way of concrete 
demonstration of benefit. Think it'd be good to see it approached from a 
perspective of "what are we actually recommending our users do here?"

Cheers & thanks to everyone for their hard work!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8120693f-652f-4767-909b-90a62505f297%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.