Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Tim Graham 
Thanks Donald, updating setuptools was the factor I missed, not Python 2 
vs. 3.

On Tuesday, November 17, 2015 at 5:06:59 PM UTC-5, Donald Stufft wrote:
>
>
> On Nov 17, 2015, at 12:00 PM, Tim Graham  
> wrote:
>
> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
> there is some other conflating factor that I missed, generating release 
> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
> release must have been the first release candidate to be generated using 
> Python 3, and this broke the download page because 
> django.utils.version.get_version() (which the website uses) returns "c1" 
> for the file name instead of "rc1". I put in a (perhaps temporary) fix to 
> correct this: https://github.com/django/djangoproject.com/pull/547
>
> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 -- I didn't track down the 
> reason why this changed in Python.
> While get_version() isn't a public API, it's widely used according to 
> GitHub search.
>
>
> Whoever generated the tarballs is probably using a version of setuptools 
> older than 8.0 in their Python 2 environment and a version of setuptools 
> newer than 8.0 in their Python 3 environment.
>
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
> DCFA 
>
>

-- 
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/e02a697f-36c4-4604-b484-1907919a6a54%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Donald Stufft 

> On Nov 17, 2015, at 12:00 PM, Tim Graham  wrote:
> 
> There was a small hiccup with the 1.9 release candidate yesterday. Unless 
> there is some other conflating factor that I missed, generating release 
> packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
> Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
> release must have been the first release candidate to be generated using 
> Python 3, and this broke the download page because 
> django.utils.version.get_version() (which the website uses) returns "c1" for 
> the file name instead of "rc1". I put in a (perhaps temporary) fix to correct 
> this: https://github.com/django/djangoproject.com/pull/547 
> 
> 
> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 
>  -- I didn't track down the 
> reason why this changed in Python.
> While get_version() isn't a public API, it's widely used according to GitHub 
> search.
> 

Whoever generated the tarballs is probably using a version of setuptools older 
than 8.0 in their Python 2 environment and a version of setuptools newer than 
8.0 in their Python 3 environment.


-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/F8D9E8C5-852C-4BDF-A8E9-C3D91CFA7972%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Donald Stufft 

> On Nov 17, 2015, at 3:03 PM, Aymeric Augustin 
>  wrote:
> 
> On 17 nov. 2015, at 18:00, Tim Graham  > wrote:
> 
>> Do you think it's correct to make the change in Django itself? 
>> https://github.com/django/django/pull/5676 
>>  -- I didn't track down the 
>> reason why this changed in Python.
> 
> 
> 
> Per PEP 386, the standard scheme is ‘c’, although ‘rc’ is acceptable as well.

PEP 386 has been superseded by PEP 440 which recommends “rc” because almost 
everyone was using “rc” and not “c”. It didn’t seem reasonable to have a 
decision which was solely bike shedding (it can handle rc as easily as it can 
handle c) to favor an option that flew in the face of what most projects were 
doing.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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/D79091CB-743C-4D96-8CAF-29718BDA61D9%40stufft.io.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Aymeric Augustin 
On 17 nov. 2015, at 18:00, Tim Graham  wrote:

> Do you think it's correct to make the change in Django itself? 
> https://github.com/django/django/pull/5676 
>  -- I didn't track down the 
> reason why this changed in Python.



Per PEP 386, the standard scheme is ‘c’, although ‘rc’ is acceptable as well.

> Pre-releases can use a for "alpha", b for "beta" and c for "release 
> candidate". rc is an alternative notation for "release candidate" that is 
> added to make the version scheme compatible with Python's own version scheme. 
> rc sorts after c.

We can take this opportunity to change the naming scheme to what Python 3 
generates by default. We just have to be careful not to generate releases with 
Python 2 from now on. I suggest to add something in the release checklist 
(assuming you still follow it when making releases, perhaps you know it by 
heart by now).

-- 
Aymeric.



-- 
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/34D2A435-48DA-47E2-A86F-FE5BF351%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: removing redirect URLs for some really old Django releases

2015-11-17 Thread Aymeric Augustin 
I hope anyone who still cares about these versions has their own copy…

-- 
Aymeric.



> On 17 nov. 2015, at 17:46, Tim Graham  wrote:
> 
> I wonder if anyone objects to removing some non-trivial logic to support old 
> download redirect URLs:
> 
> https://github.com/django/djangoproject.com/pull/548 
> 
> 
> This only affects the redirect URLs like /download/%(version)s/tarball/. The 
> files are still accessible at their actual URLs like 
> https://www.djangoproject.com/m/releases/0.90/Django-0.90.tar.gz -- the only 
> issue is that it's difficult to "guess" these URLs for packages that don't 
> use the standard names.
> 
> This affects versions like:
> 
> 0.90 Python 2.4 egg
> 0.91 Python 2.5 egg
> 1.0-alpha-2 
> 1.0-beta-1 
> 1.0-beta-2
> 1.0.1-beta-1 
> 1.0.1
> 1.0.2
> 
> -- 
> 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/e1b83dc5-c7f6-4ec1-888c-d7ed501a8de4%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/81194D6E-9B80-454A-B11D-84CE4537ADCA%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

django.utils.version.get_version() discrepancy for Python 2 vs. Python 3

2015-11-17 Thread Tim Graham 
There was a small hiccup with the 1.9 release candidate yesterday. Unless 
there is some other conflating factor that I missed, generating release 
packages using Python 2 will yield a name like "Django-1.9c1.tar.gz" while 
Python 3 yields "Django-1.9rc1.tar.gz" ('rc' instead of 'c'). Yesterday's 
release must have been the first release candidate to be generated using 
Python 3, and this broke the download page because 
django.utils.version.get_version() (which the website uses) returns "c1" 
for the file name instead of "rc1". I put in a (perhaps temporary) fix to 
correct this: https://github.com/django/djangoproject.com/pull/547

Do you think it's correct to make the change in Django itself? 
https://github.com/django/django/pull/5676 -- I didn't track down the 
reason why this changed in Python.
While get_version() isn't a public API, it's widely used according to 
GitHub search.

-- 
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/8a7f8f47-6a43-4a02-a0f5-f64461cefadf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

removing redirect URLs for some really old Django releases

2015-11-17 Thread Tim Graham 
I wonder if anyone objects to removing some non-trivial logic to support 
old download redirect URLs:

https://github.com/django/djangoproject.com/pull/548

This only affects the redirect URLs like /download/%(version)s/tarball/. The 
files are still accessible at their actual URLs like 
https://www.djangoproject.com/m/releases/0.90/Django-0.90.tar.gz -- the 
only issue is that it's difficult to "guess" these URLs for packages that 
don't use the standard names.

This affects versions like:

0.90 Python 2.4 egg
0.91 Python 2.5 egg
1.0-alpha-2 
1.0-beta-1 
1.0-beta-2
1.0.1-beta-1 
1.0.1
1.0.2

-- 
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/e1b83dc5-c7f6-4ec1-888c-d7ed501a8de4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

2015-11-17 Thread Fabio Caccamo 
Hi guys, 
I just released https://github.com/fabiocaccamo/django-admin-interface

It is based on the great Elky's theme, but by default it uses the same 
colors of https://www.djangoproject.com/ 
and as a plus it allows some interface customizations (title, logo and 
colors) directly through the admin interface itself.

It's possible to manage multiple themes and switching between them with a 
click.
Here how the theme customization admin looks like:



-- 
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/ea8e21f0-bdf6-49ae-a2d9-077bac41427e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migrations processing time of reload_model

2015-11-17 Thread Mounir Messelmeni 
Hi,

On one of my projects, I'm having processing time trouble to generate or 
run migrations even for a single app, this can take up to 3 minutes, after 
debugging I found that the function reload_model inside 
django.db.migrations.state.py take a lot of time, and this one is called 
when evaluating every migrations operation (AddField, AlterField ...)

The question is, I'm I supposed to have something wrong on my models or is 
this a common behaviour of Django's migrations?

Here a stats from cProfile for the calls for realod_model method:

353318 function calls (352524 primitive calls) in 2.859 seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
10.0000.0000.0000.000 :8(__new__)
10.0000.0000.0000.000 AES.py:55(__init__)
10.0000.0000.0000.000 AES.py:61(new)
10.0000.0000.0000.000 UserDict.py:26(clear)
   310.0010.0000.0050.000 __init__.py:1005(__init__)
   310.0000.0000.0140.000 __init__.py:1027(deconstruct)
  1550.0050.0000.0250.000 __init__.py:1080(__init__)
  2500.0030.0000.0470.000 __init__.py:112(__iter__)
  1380.0020.0000.0200.000 __init__.py:1195(__init__)
  1380.0020.0000.0570.000 __init__.py:1246(deconstruct)
  1380.0050.0000.0390.000 
__init__.py:1298(contribute_to_class)
  6930.0530.0000.0870.000 __init__.py:137(__init__)
   550.0010.0000.0090.000 __init__.py:1502(__init__)
   550.0010.0000.0260.000 __init__.py:1582(deconstruct)
50.0000.0000.0010.000 __init__.py:1707(__init__)
50.0000.0000.0020.000 __init__.py:1712(deconstruct)
  6760.0090.0000.0210.000 __init__.py:20(import_module)
20.0000.0000.0000.000 __init__.py:2033(__init__)
20.0000.0000.0010.000 __init__.py:2038(deconstruct)
40.0000.0000.0010.000 __init__.py:2118(__init__)
40.0000.0000.0010.000 __init__.py:2125(deconstruct)
  2490.0070.0000.0110.000 __init__.py:22()
50.0000.0000.0010.000 __init__.py:2310(__init__)
50.0000.0000.0020.000 __init__.py:2314(deconstruct)
10.0000.0000.0000.000 __init__.py:233(__len__)
20.0000.0000.0000.000 __init__.py:245(__bool__)
   700.0010.0000.0030.000 __init__.py:35(__getattr__)
10.0000.0000.0000.000 __init__.py:35(get_option)
   350.0010.0000.0080.000 __init__.py:352(__init__)
  6660.1280.0000.3100.000 __init__.py:358(deconstruct)
   700.0010.0000.0350.000 __init__.py:369(deconstruct)
   350.0010.0000.0070.000 __init__.py:388(__init__)
   350.0000.0000.0190.001 __init__.py:403(deconstruct)
40.0000.0000.0000.000 __init__.py:45(countries)
   150.0000.0000.0000.000 __init__.py:455(__eq__)
 18010.0140.0000.0210.000 __init__.py:46(__getattr__)
 17610.0110.0000.0190.000 __init__.py:461(__lt__)
  1580.0010.0000.0010.000 __init__.py:528(validators)
10.0000.0000.0000.000 __init__.py:64(configured)
  6930.0070.0000.0190.000 
__init__.py:647(set_attributes_from_name)
  6930.0140.0000.1660.000 
__init__.py:655(contribute_to_class)
  5980.0020.0000.0020.000 __init__.py:666(get_attname)
  5980.0070.0000.0090.000 
__init__.py:669(get_attname_column)
   950.0010.0000.0010.000 
__init__.py:674(get_cache_name)
  2490.0020.0000.0220.000 __init__.py:83(ugettext)
  6930.0060.0000.0340.000 __init__.py:854(_get_choices)
   720.0020.0000.0150.000 __init__.py:929(__init__)
   630.0010.0000.0320.001 __init__.py:951(deconstruct)
   720.0010.0000.0260.000 
__init__.py:987(contribute_to_class)
   730.0030.0000.0070.000 _abcoll.py:526(update)
 22710.0150.0000.0150.000 
_weakrefset.py:70(__contains__)
 14320.0210.0000.0400.000 abc.py:128(__instancecheck__)
   730.0010.0000.0010.000 abc.py:148(__subclasscheck__)
   730.0010.0000.0010.000 base.py:146()
   730.0010.0000.0010.000 base.py:155()
   730.0010.0000.0010.000 base.py:197()
  990/9270.0180.0000.4610.000 base.py:321(add_to_class)
   730.0060.0000.1170.002 base.py:328(_prepare)
  7570.0020.0000.0020.000