Re: Post mortem on today's packaging error.

[Florian Apolloner]

On Monday, February 11, 2019 at 11:01:55 PM UTC+1, Adam Johnson wrote:
>
> Jamesie’s suggestion to use CI is also valid but a bunch more work. I 
> guess the main advantage is you get a blank slate container to work in, 
> which a fresh checkout to a temp dir provides most of the gain for less 
> work.
>

If I remember we have been hesitant in the past because that would require 
us to give credentials to PyPi etc to the CI service. That said I think 
that is a risk we could take.

Cheers,
Florian

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fb0d567d-d01a-44d9-983a-ac0a1ba93de1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Use CDN for djangoproject.com

[Florian Apolloner]

Especially cloudflare is a service we do not want to use. as for the docs 
only, does the mirror on rtd work better for you? They are probably behind 
a CDN.

Cheers,
Florian

On Tuesday, February 12, 2019 at 6:43:41 AM UTC+1, Cheng C wrote:
>
> Hi,
>
> Is it possible to utilize a CDN service for djangoproject.com, or at 
> least on docs.djangoproject.com? The site is actually quite fast for me 
> but I think there is still room for improvement. Cloudflare sponsored 
> dozens of open source projects 
> , probably they can 
> provide free service for django as well.
>
> Tested from Melbourne, Australia:
>
> https://www.djangoproject.com/
>  Average Ping: 245ms
>  Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 
> 1.16s, Load: 1.48s
>
> https://git-scm.com/
>  Average Ping: 5ms
>  Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 
> 564ms, Load: 699ms
>
> Tested on Chrome with "Disable cache" checked (but not the first time 
> visit, so DNS query time might not be included).
>
> Best regards and thanks for all your great 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c1b5a962-a473-4f7f-84e7-fa9fa34c00a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Use CDN for djangoproject.com

[Cheng C]

Hi,

Is it possible to utilize a CDN service for djangoproject.com, or at least 
on docs.djangoproject.com? The site is actually quite fast for me but I 
think there is still room for improvement. Cloudflare sponsored dozens of 
open source projects , 
probably they can provide free service for django as well.

Tested from Melbourne, Australia:

https://www.djangoproject.com/
 Average Ping: 245ms
 Browser: 21 requests, 211KB transferred, Finish: 2.52s, DOMContentLoaded: 
1.16s, Load: 1.48s

https://git-scm.com/
 Average Ping: 5ms
 Browser: 42 requests, 351KB transferred, Finish: 717ms, DOMContentLoaded: 
564ms, Load: 699ms

Tested on Chrome with "Disable cache" checked (but not the first time 
visit, so DNS query time might not be included).

Best regards and thanks for all your great 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/450abcbb-9bf9-487b-8376-74a02eb1a779%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Post mortem on today's packaging error.

[Adam Johnson]

Thanks for the detailed post mortem Carlton.

Andrew’s suggested approach to do at least a checkout to a fresh directory
makes sense to me. Even got checkout and clean aren’t enough to bring an
exisiting checkout folder to the same state as git won’t touch files in the
gitignore. Note you can do a checkout or a local repo to a different
directory, you wouldn’t need to reclone from a different remote.

Jamesie’s suggestion to use CI is also valid but a bunch more work. I guess
the main advantage is you get a blank slate container to work in, which a
fresh checkout to a temp dir provides most of the gain for less work.

That’s my two cents

On Mon, 11 Feb 2019 at 17:30, Jamesie Pic  wrote:

> Hi Carlton !
>
> Seems like you're having as much fun as I had when doing releases
> manually :D Just sharing some food for thought here.
>
> Nowadays I have it automated and rely on setupmeta to keep myself away
> from touching setup.py, and just have to push git tags :
> http://github.com/zsimic/setupmeta
>
> Then a silly little script like that to publish to pypi :
> https://yourlabs.io/oss/shyml/blob/master/shyml/sh.yml
>
> All python modules on yourlabs.io/oss have this kind of setup ... of
> course you're still stuck on jenkins so I can understand it's not as
> flexible as say gitlab-ci or drone-ci, but there's probably also a
> way.
>
> Hope this helps
>
> Keep up the good work, you'll make it !
>
> Have a great day
>
> --
> ∞
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAC6Op1_rgn8BnHHS-0%2B05yMKFi5g%2Bq%2BKmHZVz1-SP-sgxY-%3D3Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM3EUDHDCD_97cyYL-p772Pnpry2eKPK6%3D0dvOD%3DxnOBNA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Jani Tiainen]

Hi,

As we are heavy ExtJS and DojoToolkit users we've encountered quite a much
problems since both frameworks do have their own toolchain and it doesn't
seem to fit to webpack or rollup or anything like that.

So if such a feature is planned for core I really hope that non mainstream
tools are left out, at least without possibility to make them work easily.


On Mon, Feb 11, 2019 at 12:50 AM Josh Smeaton 
wrote:

> For the vast majority of users, right now, Vue or React are the only real
> options. Let's not try predicting the future, and just focus on what the
> trends currently are. Users going for newer targets are likely more
> advanced, and can figure out the necessary changes.
>
> Aymerics articles are fantastic, and our team has gotten a lot of value
> out of them for our newer projects. Especially the customisations to static
> files which removes the re-hashing of static content. I would be very keen
> for Django to provide a first class integration method with Webpack, in
> particular, but most popular bundler frameworks if the necessary interfaces
> exist.
>
> - "Importing" static content that has already been bundled and hashed
> - Automatic reloading of static content as it is being changed
> - Visual debugging in editors
>
> I think the idea of a how-to that considers authentication and
> communication between frontend and backend is also what we need.
>
> So while I don't think Django needs to bless a particular frontend
> framework, I think we have to provide a really nice integration story so
> that the most popular JS frameworks do not have to jump through a lot of
> hoops, including copy and pasting large sections of code, to get their
> existing tooling working with Django. I no longer think it's enough to
> require 3rd party django libraries to make the frontend integration
> possible.
>
> On Sunday, 10 February 2019 04:50:54 UTC+11, Dmitriy Sintsov wrote:
>>
>> Very nice tuturials! Although there is web components standard gradually
>> being adapted by major browsers, which should bring custom tags /
>> components not having to use the third party Javascript libraries like Vue
>> or React. So, while in Python world the leadership of Django is quite
>> stable and obvious one, in Javascript world it's not so easy to say whether
>> Vue and React would dominate in a long run. Maybe Marko or Stencil.js are
>> closer to the future vision of Javascript.
>>
>> On Sat, Feb 9, 2019 at 8:32 PM Aymeric Augustin <
>> aymeric@polytechnique.org> wrote:
>>
>>> Hello,
>>>
>>> I wrote a three-part essay on this question last year:
>>> 1.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together/
>>> 2.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together-hybrid-app-model/
>>> 3.
>>> https://fractalideas.com/blog/making-react-and-django-play-well-together-single-page-app-model/
>>>
>>> Even though I took a narrower view — I only considered React — I found
>>> enough decisions factors to write over 2000 words in the first post, which
>>> is too long for a FAQ :-)
>>>
>>> On one hand, I'm not sure the Django docs should go into this level of
>>> detail and provide specific information about a particular JS framework. On
>>> the other hand, it's rather useless to talk about integrating Django with a
>>> JS frontend without discussing authentication and it's hard to discuss
>>> authentication in less than 2000 words — which were just for justifying my
>>> favorite solution, not for investigating every option!
>>>
>>> I think we need a how-to guide rather than a FAQ entry. I would find it
>>> nice:
>>>
>>> *A. To describe the Singe Page App model — where Django only serves the
>>> API*
>>>
>>> We need to explain CORS and CSRF in the clearest terms possible. Many
>>> devs end up shotgun-debugging CORS or CSRF errors, which always results in
>>> insecure deployments.
>>>
>>> My consulting experience suggests that we have a problem there: I never
>>> did an audit where the client got that right, even though they're all smart
>>> people trying to get things right.
>>>
>>> Perhaps a condensed version of my third post could do the job?
>>>
>>> Some may disagree with my recommendation against JWT, which may too
>>> opinionated for the Django docs. Again, in my experience, people tend to
>>> get security more wrong with JWT, which is why I prefer discouraging it and
>>> letting those who know what they're doing ignore my advice.
>>>
>>> *B. To say something about integrating a modern JS framework with
>>> django.contrib.staticfiles *
>>>
>>> It's perfectly doable and provides all the benefits of
>>> django.contrib.staticfiles. However, it requires a bit of duct tape, as
>>> shown in my second post.
>>>
>>> I'm a huge fan of this technique for simple website but I'm afraid I'm
>>> biased by my experience with Django. This is unlikely to be a popular
>>> option for those who are more familiar with a modern frontend framework
>>> than with django.contrib.staticfiles.
>>>

Re: Post mortem on today's packaging error.

[Jamesie Pic]

Hi Carlton !

Seems like you're having as much fun as I had when doing releases
manually :D Just sharing some food for thought here.

Nowadays I have it automated and rely on setupmeta to keep myself away
from touching setup.py, and just have to push git tags :
http://github.com/zsimic/setupmeta

Then a silly little script like that to publish to pypi :
https://yourlabs.io/oss/shyml/blob/master/shyml/sh.yml

All python modules on yourlabs.io/oss have this kind of setup ... of
course you're still stuck on jenkins so I can understand it's not as
flexible as say gitlab-ci or drone-ci, but there's probably also a
way.

Hope this helps

Keep up the good work, you'll make it !

Have a great day

-- 
∞

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAC6Op1_rgn8BnHHS-0%2B05yMKFi5g%2Bq%2BKmHZVz1-SP-sgxY-%3D3Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Post mortem on today's packaging error.

[Andrew Godwin]

I also ran into this several times while releasing Channels - several
releases had the wrong files ship out in them due to Git weirdness.

In the end, my solution was to build the release artifacts over on Travis
to guarantee a fresh build environment each time, but I doubt that would
work for Django. Adding "git clean" to the script is probably good enough,
but I might be tempted to make a script where you pass it a commit hash and
it checks it out to a fresh temporary directory and packages from there?

Andrew

On Mon, Feb 11, 2019 at 8:28 AM Carlton Gibson 
wrote:

> Hi all.
>
> This morning I released four versions of Django. Three of which, for 2.1,
> 2.0 and 1.11. (i.e. all the actually supported versions) were broken.
> In the package were additional files from `master`/2.2 which shouldn't
> have been there.
>
> This afternoon I have released follow-ups to correct this issue.
>
> First of all, sorry about that, and for any inconvenience caused.
>
>
> Then, these are process issues so, how can we do better next time?
>
> I'm not 100% sure what occurred.
>
> * The history in Git is correct.
> * I must have had the right commits checked out, because the package
> metadata is correct. (Filenames, version numbers and so on.)
>
> My best guess is that I've failed to `git clean` correctly before building
> each release.
> I'm not certain here because switching between branches doesn't leave the
> repos in an unclean state, and I'm pretty sure it was clean, but this seems
> the most likely error.
>
>
> Q: is there a nice git command to "assert I'm at exactly this tag"?
>
>
> Steps I've taken:
>
> * Moved the `git clean` step into the helper script used to build the
> packages. No chance of then missing it.
> * Added a `diff`-step after building just to make sure what's in the
> `django` module matches the checkout.
>
> The second of these, whilst just a visual check, would have worked with
> what ended up in the package vs what was in my working tree when I checked
> later, but I'm not sure it would have caught the issue when the package was
> created (because presumably my working tree was wrong at that point).
>
> A similar issue affects the checksums, which check that nothing changed
> since it was packaged, but not that the right things were packaged...
> (Similarly, pip install worked without error.)
>
> On the new 1.11 package, I created a virtualenv with Python 2 and ran the
> test suite. This worked so it should be good. But it would be good to
> automate this.
> (I'll look into it.) We don't ship the tests in the wheel, so we have to
> use the src-dist for this. (We could then diff the two django modules to
> make sure they were the same.)
>
> On the other packages I visually looked for incorrect files, but, beyond
> specific migrations (etc) that were known bad from the previous release,
> this doesn't generalise.
>
> "zaytsev" on IRC suggested running `makemigrations --check`, so having a
> test project to install against might also be worth it.
> (I'd guess running the test suite would be sufficient...)
>
>
> Any other thoughts very welcome.
>
>
> Kind Regards,
>
> Carlton
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/90c531fc-3d5b-4d9e-a55f-b88f2e04bb54%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uqvLhhEoB2WFy%3DC4KWA2gLns%3DadhCGwfnYidJsHOjVpUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: include only columns from selected related models in select_related query

[Riccardo Magliocchetti]

Hello Collin,

Il 11/02/19 17:35, Collin Anderson ha scritto:

So would you "defer" the other columns like "only()"?


Yeah, something like that


If nothing else, you could try using .annotate(F('author__hometown')) (not
sure if that works) or .values('author__hometown') to just get the values
you need.


Sure but the query would be everything but readable :)
The point of a parameter to select_related would be to avoid to type explicitly 
fields not in select_related and the one in select_related twice.



On Mon, Feb 11, 2019 at 5:50 AM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:


Hello,

I'm debugging views leaking lots of memory in django 1.11. It looks like
there
is some connections with my usage of select_related(). But that's mail is
not
about that, not sure about my findings yet :)

So I have looked again at the select_related documentation here:
https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related

and found this:
Book.objects.select_related('author__hometown').get(id=4) will cache the
related
Person and the related City

Up until now i thought that only the related model i've specified would
get
added to selected columns e.g. only the City because of hometown. But it
looks
that's not how it is :)

Would it make sense to add a parameter to change select_related behaviour
to
include only the columns of the related models specified? That could save
quite
a lot of bandwitdh for some use cases.

What do you think?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/a42050d3-25a2-2f47-c841-918d7d085757%40gmail.com
.
For more options, visit https://groups.google.com/d/optout.






--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4755ef5-26af-ffee-a7c1-4c12f0f850e6%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: include only columns from selected related models in select_related query

[Collin Anderson]

So would you "defer" the other columns like "only()"?

If nothing else, you could try using .annotate(F('author__hometown')) (not
sure if that works) or .values('author__hometown') to just get the values
you need.

On Mon, Feb 11, 2019 at 5:50 AM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

> Hello,
>
> I'm debugging views leaking lots of memory in django 1.11. It looks like
> there
> is some connections with my usage of select_related(). But that's mail is
> not
> about that, not sure about my findings yet :)
>
> So I have looked again at the select_related documentation here:
> https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related
>
> and found this:
> Book.objects.select_related('author__hometown').get(id=4) will cache the
> related
> Person and the related City
>
> Up until now i thought that only the related model i've specified would
> get
> added to selected columns e.g. only the City because of hometown. But it
> looks
> that's not how it is :)
>
> Would it make sense to add a parameter to change select_related behaviour
> to
> include only the columns of the related models specified? That could save
> quite
> a lot of bandwitdh for some use cases.
>
> What do you think?
>
> Thanks
>
> --
> Riccardo Magliocchetti
> @rmistaken
>
> http://menodizero.it
>
> --
> 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a42050d3-25a2-2f47-c841-918d7d085757%40gmail.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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S5M8o1ONpfm%3D27ofFRcYCeU%2B-pGxNmTbm7q1kKC6Mk64w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Post mortem on today's packaging error.

[Carlton Gibson]

Hi all. 

This morning I released four versions of Django. Three of which, for 2.1, 
2.0 and 1.11. (i.e. all the actually supported versions) were broken. 
In the package were additional files from `master`/2.2 which shouldn't have 
been there. 

This afternoon I have released follow-ups to correct this issue. 

First of all, sorry about that, and for any inconvenience caused. 


Then, these are process issues so, how can we do better next time? 

I'm not 100% sure what occurred. 

* The history in Git is correct. 
* I must have had the right commits checked out, because the package 
metadata is correct. (Filenames, version numbers and so on.) 

My best guess is that I've failed to `git clean` correctly before building 
each release. 
I'm not certain here because switching between branches doesn't leave the 
repos in an unclean state, and I'm pretty sure it was clean, but this seems 
the most likely error.


Q: is there a nice git command to "assert I'm at exactly this tag"?  


Steps I've taken: 

* Moved the `git clean` step into the helper script used to build the 
packages. No chance of then missing it. 
* Added a `diff`-step after building just to make sure what's in the 
`django` module matches the checkout. 
 
The second of these, whilst just a visual check, would have worked with 
what ended up in the package vs what was in my working tree when I checked 
later, but I'm not sure it would have caught the issue when the package was 
created (because presumably my working tree was wrong at that point). 

A similar issue affects the checksums, which check that nothing changed 
since it was packaged, but not that the right things were packaged...
(Similarly, pip install worked without error.) 

On the new 1.11 package, I created a virtualenv with Python 2 and ran the 
test suite. This worked so it should be good. But it would be good to 
automate this. 
(I'll look into it.) We don't ship the tests in the wheel, so we have to 
use the src-dist for this. (We could then diff the two django modules to 
make sure they were the same.) 

On the other packages I visually looked for incorrect files, but, beyond 
specific migrations (etc) that were known bad from the previous release, 
this doesn't generalise. 

"zaytsev" on IRC suggested running `makemigrations --check`, so having a 
test project to install against might also be worth it. 
(I'd guess running the test suite would be sufficient...) 


Any other thoughts very welcome. 


Kind Regards,

Carlton

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/90c531fc-3d5b-4d9e-a55f-b88f2e04bb54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django bugfix releases: 2.1.7, 2.0.12 and 1.11.20

[Carlton Gibson]

Updated releases correcting a packaging issue from this morning are now 
available for the 2.1, 2.0 and 1.11 release branches. 

https://www.djangoproject.com/weblog/2019/feb/11/bugfix-releases/ 



-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4FDCEA5F-D8BC-4F9C-8B0B-FB6F02DDEE59%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

DJANGO FILE

[Edward Victorhez]

PLEASE I  AM NEW IN DJANGO, PLEASE I NEED THE FILES THAT WILL PUT ME THROUGH

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4bc81098-6d8b-43dd-bafe-2412061a292a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Carlton Gibson]

On Monday, 11 February 2019 13:46:04 UTC+1, Bruno Alla wrote:
>
>  Did something go wrong during the release publication?
>

Yes. Additional files were packaged. (In all except the 2.2b1 release as 
far as I can tell.) 

I will release updated versions shortly.

I'll then publish a post-mortem.

C. 

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1fb176e7-b477-4d47-ad8f-6d62df89865c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Bruno Alla]

It looks like 2.1.6 has unexpected new migrations as well 
https://code.djangoproject.com/ticket/30174

 Did something go wrong during the release publication?

On Monday, 11 February 2019 12:07:19 UTC, Raffaele Salmaso wrote:
>
> On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti <
> riccardo.ma...@gmail.com > wrote:
>
>> InvalidTemplateLibrary: Invalid template library specified. ImportError 
>> raised 
>> when trying to load 'django.contrib.admin.templatetags.base': cannot 
>> import name 
>> getfullargspec
>>
>> 1.11.18 works fine for the same test.
>>
> Hi Riccardo, please check if you use the correct django version, 
> django.contrib.admin.templatetags.base is there from django 2.1
>
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6656afc-c8d5-47bf-8127-b5643e6145e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Carlton Gibson]

On Monday, 11 February 2019 13:15:12 UTC+1, riccardo.magliocchetti wrote:
>
>
> Yeah, what i'm reporting is that the wheel pip downloaded here does not 
> match 
> the 1.11.19 tag in git. 
>

OK. Thanks. I'll have a look.  

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0d9ef728-cd44-4754-a31a-cf604fe6afbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Riccardo Magliocchetti]

Il 11/02/19 13:06, Raffaele Salmaso ha scritto:

On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:


InvalidTemplateLibrary: Invalid template library specified. ImportError
raised
when trying to load 'django.contrib.admin.templatetags.base': cannot
import name
getfullargspec

1.11.18 works fine for the same test.


Hi Riccardo, please check if you use the correct django version,
django.contrib.admin.templatetags.base is there from django 2.1


Yeah, what i'm reporting is that the wheel pip downloaded here does not match 
the 1.11.19 tag in git.


--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fd8fde53-2e3b-84b4-4fcf-154a82771515%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Riccardo Magliocchetti]

Hello Carlton,

filed here:
https://code.djangoproject.com/ticket/30175

Il 11/02/19 12:58, Carlton Gibson ha scritto:

Hi Riccardo.

Please open a Trac ticket for this. (Current test suite passes, so it looks
like we're missing coverage somewhere.)
Thanks.

On Monday, 11 February 2019 12:26:04 UTC+1, riccardo.magliocchetti wrote:


Hello Carlton,

Il 11/02/19 12:02, Carlton Gibson ha scritto:

Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our

security process. These releases address a security issue, and we encourage
all users to upgrade as soon as possible:


https://www.djangoproject.com/weblog/2019/feb/11/security-releases/



1.11.19 blew my tests on python 2.7, python3 works fine:
File "/usr/local/lib/python2.7/site-packages/django/template/base.py",
line
184, in __init__
  engine = Engine.get_default()
File
"/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line
124, in wrapper
  result = user_function(*args, **kwds)
File
"/usr/local/lib/python2.7/site-packages/django/template/engine.py", line
76, in get_default
  django_engines = [engine for engine in engines.all()
File "/usr/local/lib/python2.7/site-packages/django/template/utils.py",
line
89, in all
  return [self[alias] for alias in self]
File "/usr/local/lib/python2.7/site-packages/django/template/utils.py",
line
80, in __getitem__
  engine = engine_cls(params)
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 30, in __init__
  options['libraries'] = self.get_templatetag_libraries(libraries)
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 48, in get_templatetag_libraries
  libraries = get_installed_libraries()
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 113, in get_installed_libraries
  for name in get_package_libraries(pkg):
File
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py",

line 130, in get_package_libraries
  "trying to load '%s': %s" % (entry[1], e)
InvalidTemplateLibrary: Invalid template library specified. ImportError
raised
when trying to load 'django.contrib.admin.templatetags.base': cannot
import name
getfullargspec

1.11.18 works fine for the same test.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it






--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/934e1e54-a7c0-432c-af55-5679bc698ea0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Raffaele Salmaso]

On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com> wrote:

> InvalidTemplateLibrary: Invalid template library specified. ImportError
> raised
> when trying to load 'django.contrib.admin.templatetags.base': cannot
> import name
> getfullargspec
>
> 1.11.18 works fine for the same test.
>
Hi Riccardo, please check if you use the correct django version,
django.contrib.admin.templatetags.base is there from django 2.1

-- 
| Raffaele Salmaso
| https://salmaso.org
| https://bitbucket.org/rsalmaso
| https://github.com/rsalmaso

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABgH4JtXzPVmJdJEMOqxvHS2Kc249Xcybvdmy%3DXxCqWSBj4%2Bkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Carlton Gibson]

Hi Riccardo. 

Please open a Trac ticket for this. (Current test suite passes, so it looks 
like we're missing coverage somewhere.) 
Thanks.

On Monday, 11 February 2019 12:26:04 UTC+1, riccardo.magliocchetti wrote:
>
> Hello Carlton, 
>
> Il 11/02/19 12:02, Carlton Gibson ha scritto: 
> > Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our 
> security process. These releases address a security issue, and we encourage 
> all users to upgrade as soon as possible: 
> > 
> > https://www.djangoproject.com/weblog/2019/feb/11/security-releases/ 
> > 
>
> 1.11.19 blew my tests on python 2.7, python3 works fine: 
>File "/usr/local/lib/python2.7/site-packages/django/template/base.py", 
> line 
> 184, in __init__ 
>  engine = Engine.get_default() 
>File 
> "/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line 
> 124, in wrapper 
>  result = user_function(*args, **kwds) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/engine.py", line 
> 76, in get_default 
>  django_engines = [engine for engine in engines.all() 
>File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", 
> line 
> 89, in all 
>  return [self[alias] for alias in self] 
>File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", 
> line 
> 80, in __getitem__ 
>  engine = engine_cls(params) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 30, in __init__ 
>  options['libraries'] = self.get_templatetag_libraries(libraries) 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 48, in get_templatetag_libraries 
>  libraries = get_installed_libraries() 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 113, in get_installed_libraries 
>  for name in get_package_libraries(pkg): 
>File 
> "/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
>
> line 130, in get_package_libraries 
>  "trying to load '%s': %s" % (entry[1], e) 
> InvalidTemplateLibrary: Invalid template library specified. ImportError 
> raised 
> when trying to load 'django.contrib.admin.templatetags.base': cannot 
> import name 
> getfullargspec 
>
> 1.11.18 works fine for the same test. 
>
> -- 
> Riccardo Magliocchetti 
> @rmistaken 
>
> http://menodizero.it 
>

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2d1dcdb6-9049-4c10-8f81-ff7a159c3383%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Riccardo Magliocchetti]

Hello Carlton,

Il 11/02/19 12:02, Carlton Gibson ha scritto:

Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our security 
process. These releases address a security issue, and we encourage all users to 
upgrade as soon as possible:

https://www.djangoproject.com/weblog/2019/feb/11/security-releases/



1.11.19 blew my tests on python 2.7, python3 works fine:
  File "/usr/local/lib/python2.7/site-packages/django/template/base.py", line 
184, in __init__

engine = Engine.get_default()
  File "/usr/local/lib/python2.7/site-packages/django/utils/lru_cache.py", line 
124, in wrapper

result = user_function(*args, **kwds)
  File "/usr/local/lib/python2.7/site-packages/django/template/engine.py", line 
76, in get_default

django_engines = [engine for engine in engines.all()
  File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", line 
89, in all

return [self[alias] for alias in self]
  File "/usr/local/lib/python2.7/site-packages/django/template/utils.py", line 
80, in __getitem__

engine = engine_cls(params)
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 30, in __init__

options['libraries'] = self.get_templatetag_libraries(libraries)
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 48, in get_templatetag_libraries

libraries = get_installed_libraries()
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 113, in get_installed_libraries

for name in get_package_libraries(pkg):
  File 
"/usr/local/lib/python2.7/site-packages/django/template/backends/django.py", 
line 130, in get_package_libraries

"trying to load '%s': %s" % (entry[1], e)
InvalidTemplateLibrary: Invalid template library specified. ImportError raised 
when trying to load 'django.contrib.admin.templatetags.base': cannot import name 
getfullargspec


1.11.18 works fine for the same test.

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/65914ae6-3647-322e-8b58-d4c095a4967f%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django 2.2 beta 1 released

[Carlton Gibson]

We've made the second release on the way to Django's next major 
release, Django 2.2! With less than two months until the final release, 
we'll need timely testing from the community to ensure a stable 
release. Check out the blog post: 

https://www.djangoproject.com/weblog/2019/feb/11/django-22-beta-1-released/


-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7A5024B3-17A8-44F6-9784-4FAE0733C1F2%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Carlton Gibson]

Today the Django team issued 2.1.6, 2.0.11, and 1.11.19 as part of our security 
process. These releases address a security issue, and we encourage all users to 
upgrade as soon as possible: 

https://www.djangoproject.com/weblog/2019/feb/11/security-releases/

-- 
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1EB1699A-228E-4151-9726-50042904A4CE%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

include only columns from selected related models in select_related query

[Riccardo Magliocchetti]

Hello,

I'm debugging views leaking lots of memory in django 1.11. It looks like there 
is some connections with my usage of select_related(). But that's mail is not 
about that, not sure about my findings yet :)


So I have looked again at the select_related documentation here:
https://docs.djangoproject.com/en/2.1/ref/models/querysets/#select-related

and found this:
Book.objects.select_related('author__hometown').get(id=4) will cache the related 
Person and the related City


Up until now i thought that only the related model i've specified would get 
added to selected columns e.g. only the City because of hometown. But it looks 
that's not how it is :)


Would it make sense to add a parameter to change select_related behaviour to 
include only the columns of the related models specified? That could save quite 
a lot of bandwitdh for some use cases.


What do you think?

Thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a42050d3-25a2-2f47-c841-918d7d085757%40gmail.com.
For more options, visit https://groups.google.com/d/optout.