Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

Is it OK to reopen that ticket?

The problem is that python2 and python3 need to coexist in most systems, and 
you can’t just rename python3 to python.

-bobby

> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
> 
> It was tried in https://code.djangoproject.com/ticket/27878 
>  but it caused problems, 
> particularly on Windows.
> 
> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
> I think you're right and PEP394 is the relevant text: 
> https://www.python.org/dev/peps/pep-0394/ 
> 
> 
> TL;DR
> 
> For now, python should refer to python2 and python3 should be used to refer 
> to python 3.
> 
> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
> The header of manage.py has: #!/usr/bin/env python
> 
> Shoudn’t it be: #!/usr/bin/env python3
> 
> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have 
> Python 3.5+ as “python3". (I’m not sure about Linux or other environments).
> 
> Is that a bug I need to file?
> 
> -bobby
> 
> -- 
> 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/7cdf48bb-ab0b-449d-8f33-a4c6d369%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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Tom Forbes]

This only seems to be an issue when you are using the base system
interpreter to run manage.py. installing Django and other dependencies
there is not recommended for a variety of reasons, and this isn't a problem
when using a virtualenv, it doesn't seem like there is much to fix IMO.


On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  wrote:

> Is it OK to reopen that ticket?
>
> The problem is that python2 and python3 need to coexist in most systems,
> and you can’t just rename python3 to python.
>
> -bobby
>
> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
>
> It was tried in https://code.djangoproject.com/ticket/27878 but it caused
> problems, particularly on Windows.
>
> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>>
>> I think you're right and PEP394 is the relevant text:
>> https://www.python.org/dev/peps/pep-0394/
>>
>> TL;DR
>>
>> For now, *python* should refer to python2 and *python3* should be used
>> to refer to python 3.
>>
>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>>>
>>> The header of manage.py has: #!/usr/bin/env python
>>>
>>> Shoudn’t it be: #!/usr/bin/env python3
>>>
>>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments
>>> have Python 3.5+ as “python3". (I’m not sure about Linux or other
>>> environments).
>>>
>>> Is that a bug I need to file?
>>>
>>> -bobby
>>>
>>
> --
> 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/7cdf48bb-ab0b-449d-8f33-a4c6d369%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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%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/CAFNZOJORs_f%3D70fkjdCRX%2BHwY4%2B%3DTk2Ns8TZwU-m7zboTY8Ssg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Shouldn't manage.py call python3 instead of python?

[Bobby Mozumder]

I never really liked the idea of using VirtualEnv or HomeBrew over the default 
installation in Mac OS.  (FreeBSD has the same naming issues).  

Having beginners use VirtualEnv or HomeBrew always struck me as a huge obstacle 
to getting a beginners Django developer's environment operational, as well as 
being a huge pain-in-the-ass of always setting VirtualEnvs for each shell.  So, 
I personally don’t use them anymore, and just use the base system now.

I wish there was a process of running Django out-of-the-box from a default Mac 
OS install.

-bobby

> On Apr 8, 2018, at 8:27 AM, Tom Forbes  wrote:
> 
> This only seems to be an issue when you are using the base system interpreter 
> to run manage.py. installing Django and other dependencies there is not 
> recommended for a variety of reasons, and this isn't a problem when using a 
> virtualenv, it doesn't seem like there is much to fix IMO.
> 
> 
> On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  > wrote:
> Is it OK to reopen that ticket?
> 
> The problem is that python2 and python3 need to coexist in most systems, and 
> you can’t just rename python3 to python.
> 
> -bobby
> 
>> On Apr 6, 2018, at 8:30 PM, Tim Graham > > wrote:
>> 
>> It was tried in https://code.djangoproject.com/ticket/27878 
>>  but it caused problems, 
>> particularly on Windows.
>> 
>> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>> I think you're right and PEP394 is the relevant text: 
>> https://www.python.org/dev/peps/pep-0394/ 
>> 
>> 
>> TL;DR
>> 
>> For now, python should refer to python2 and python3 should be used to refer 
>> to python 3.
>> 
>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>> The header of manage.py has: #!/usr/bin/env python
>> 
>> Shoudn’t it be: #!/usr/bin/env python3
>> 
>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments have 
>> Python 3.5+ as “python3". (I’m not sure about Linux or other environments).
>> 
>> Is that a bug I need to file?
>> 
>> -bobby
>> 
>> -- 
>> 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/7cdf48bb-ab0b-449d-8f33-a4c6d369%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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%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/CAFNZOJORs_f%3D70fkjdCRX%2BHwY4%2B%3DTk2Ns8TZwU-m7zboTY8Ssg%40mail.gmail.com
>  
> 

Re: Setting defaults in the DB to support zero-downtime migrations

[Ryan Hiebert]

I've found other places where things are fiddly for production migrations
as well. Migrating a nullable to a non-nullable field is one of a range of
cases where the migration cannot be run until the code has been fully
deployed to no longer write nulls to the database. A similar case, that's
even a little bit more tricky, is removing fields. It's not sufficient in
general to just avoid using the field in your user code. You also have to
remove the field from the model itself, or else the model in many cases
will, by default, attempt to gather that field from the database and cause
an error.

I'm using Heroku, and that meant that I needed to have a first commit that
removed the field from the model, and leave the migration for a second
commit (and deployment). This meant that there was a time where things were
inconsistent. In the case of removing the null-ability of a field (assuming
that in your situation it won't take the lock for longer than you can
permit) they would not have to be split into a separate commit, but the
code needs to be fully deployed before the migration can be run.

Things got even more complicated when I wanted to start using Heroku's
Release Phase to automatically run migrations, which would automatically
migrate _before_ the release is out, which doesn't work for either the
to-not-null case or attempting to remove a field in a single commit. My
team addressed that by introducing a concept of "safe" migrations, which
for us is referring to the ability to run it before the associated code is
released. Now we have a `safemigrate` command, which will only run
migrations that are safe, based on the presence of a manual property added
to the migration classes, and thus is acceptable to always run in the
release phase. This allows us to mark migrations as unsafe when we need to
ensure that a migration gets run manually after the associated code is
deployed.

There are a couple complexities with the approach, especially related to
dealing with sets of inter-dependent migrations where some are safe and
some are unsafe, but the approach does seem to be working for us. A known
challenge, but one that is, for our purposes, enough of an edge-case that
we've not addressed it, is that the reverse of safe migrations are often
unsafe, and the reverse of unsafe migrations are often safe. This is
further complicated because in some cases, such as data migrations, the
forward and reverse may _both_ be safe or unsafe, so it's not as simple as
being the opposite of the forward direction. We have, so far, completely
ignored this bit of complexity. We also have not attempted to automatically
figure out whether a migration is safe or not based on the operations
included.

If what we've done here is of interest to others, I will look into sharing
the code to get further feedback on it. Please let me know if you're
interested in seeing it.

On Thu, Mar 22, 2018 at 10:19 PM, Paul Tiplady  wrote:

> It can be quite fiddly to support zero-downtime DB migrations in Django.
> For example see https://dev.mysql.com/doc/refman/5.7/en/data-type-
> defaults.html for tricks in Postgres; I'll refer to MySQL herein.
>
> In general the sequence is to first upgrade the DB schema to the new
> version, while keeping the old version of the application running. This
> works if the DB fields have a `DEFAULT NULL`, or if strict mode is not
> enabled; in either case omitted fields are defaulted to NULL or the
> implicit default, respectively  (under MySQL).
>
> However it seems that manual SQL must be written in order to support
> adding fields that aren't nullable; since Django's ORM drops the DB-level
> default when the field is not nullable, there's a window after the schema
> migration, but before the application code has been upgraded, where the
> old-version code could try to write a None to the DB, while the new-version
> DB schema doesn't support it.
>
> For example, a NullBooleanField(default=None) produces this SQL:
>
> `bool_field` tinyint(1) DEFAULT NULL,
>
> Whereas a BooleanField(default=False) (or NullBooleanField with a default)
> produces:
>
> `bool_field` tinyint(1),
>
> This is the same for the other field types I've investigated; Django
> explicitly removes the default from the DB when migrating from a Nullable
> Field to a non-Nullable one.
>
> In MySQL using non-strict mode, this would often go unnoticed (since MySQL
> coerces NULL to the implicit default in that case), but under strict mode
> is recommended, that option is not available (per
> https://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html).
>
> Achieving zero-downtime migrations would be much easier if the default
> value was set in the DB; is there a reason that Django does not do this?
> Even if this was an optional flag which only worked for literal values
> (i.e. not functions), it would seem to be a very useful feature. (e.g.
> `Field(set_default_in_db=True)`).
>
> Indeed it seems to me that (based on the paucity of articles/documenta

Re: Shouldn't manage.py call python3 instead of python?

[Tom Forbes]

It may be an obstacle but I believe it’s better than having them nuke their
base systems by accident by installing a package that conflicts with their
base system. This isn’t such a huge issue on MacOS but on Linux it is and
I’ve seen it happen a few times. Not to mention the issue of multiple
conflicting dependencies across projects - all in all it’s really not a
recommended and we should not look to make it easier IMO.

People have different setups and whatever works, works, but things like
pipenv are maturing rapidly and solve the convenience issue you describe. I
personally use virtualenvwrapper which is really simple to set up and
displays the current virtual environment in the prompt, and makes it really
easy to switch between them/create new ones.

Tom



On 8 April 2018 at 15:00:46, Bobby Mozumder (bmozum...@gmail.com) wrote:

I never really liked the idea of using VirtualEnv or HomeBrew over the
default installation in Mac OS.  (FreeBSD has the same naming issues).

Having beginners use VirtualEnv or HomeBrew always struck me as a huge
obstacle to getting a beginners Django developer's environment operational,
as well as being a huge pain-in-the-ass of always setting VirtualEnvs for
each shell.  So, I personally don’t use them anymore, and just use the base
system now.

I wish there was a process of running Django out-of-the-box from a default
Mac OS install.

-bobby

On Apr 8, 2018, at 8:27 AM, Tom Forbes  wrote:

This only seems to be an issue when you are using the base system
interpreter to run manage.py. installing Django and other dependencies
there is not recommended for a variety of reasons, and this isn't a problem
when using a virtualenv, it doesn't seem like there is much to fix IMO.


On Sun, 8 Apr 2018, 08:19 Bobby Mozumder,  wrote:

> Is it OK to reopen that ticket?
>
> The problem is that python2 and python3 need to coexist in most systems,
> and you can’t just rename python3 to python.
>
> -bobby
>
> On Apr 6, 2018, at 8:30 PM, Tim Graham  wrote:
>
> It was tried in https://code.djangoproject.com/ticket/27878 but it caused
> problems, particularly on Windows.
>
> On Friday, April 6, 2018 at 6:35:50 PM UTC-4, Josh Smeaton wrote:
>>
>> I think you're right and PEP394 is the relevant text:
>> https://www.python.org/dev/peps/pep-0394/
>>
>> TL;DR
>>
>> For now, *python* should refer to python2 and *python3* should be used
>> to refer to python 3.
>>
>> On Saturday, 7 April 2018 07:07:35 UTC+10, Bobby Mozumder wrote:
>>>
>>> The header of manage.py has: #!/usr/bin/env python
>>>
>>> Shoudn’t it be: #!/usr/bin/env python3
>>>
>>> Since 2.0 is now only Python3. Both my Mac OS & FreeBSD environments
>>> have Python 3.5+ as “python3". (I’m not sure about Linux or other
>>> environments).
>>>
>>> Is that a bug I need to file?
>>>
>>> -bobby
>>>
>>
> --
> 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/7cdf48bb-ab0b-449d-8f33-a4c6d369%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/E1881F92-2D8C-45D8-8315-E5D72D0D7B6E%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/CAFNZOJORs_f%3D70fkjdCRX%2BHwY4%2B%3DTk2Ns8TZwU-m7zboTY8Ssg%40mail.gmail.com

#28779 needs qualified opinion from devs, customizing REDIRECT_FIELD_NAME is cumbersome

[bukow bukowiec]

https://code.djangoproject.com/ticket/28779
It was proposed to mention that ticket in the Developers Mailing list, so 
this is what i do :)

Can someone qualified say?

-- 
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/89675ae1-6e16-463e-9fb0-2ca209d4f3d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: #28779 needs qualified opinion from devs, customizing REDIRECT_FIELD_NAME is cumbersome

[Tim Graham]

What I tried to suggest there is that if this problem affects you, please 
describe your use case and how you are currently solving the issue (if at 
all) and what changes you propose to make to Django to resolve the ticket.

On Sunday, April 8, 2018 at 1:53:55 PM UTC-4, bukow bukowiec wrote:
>
> https://code.djangoproject.com/ticket/28779
> It was proposed to mention that ticket in the Developers Mailing list, so 
> this is what i do :)
>
> Can someone qualified say?
>

-- 
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/ebf96da4-b7f2-497f-aa21-b29f0926f025%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.