Re: Migration "rebase", or just an "undo" that works with conflicts

[Andrew Godwin]

You can undo a migration manually using migrate, though if you're in
multiple-tip-migration scenario you may need to make a merge migration
first (but not apply it) or switch to a branch with only the migration you
wish to undo.

The more general rebase command would be interesting, though I've always
been wary about adding one, as it's not a guarantee we can always keep -
some operations are irreversible, and in Django's case, a migration may not
be undoable without other related migrations for foreignkeys, so deleting a
migration would likely require deletion of those target migrations as well,
potentially?

Andrew


On Mon, Nov 30, 2015 at 7:33 PM, Silvio  wrote:

> I've had this situation come up too. It would indeed be very useful.
>
> Django South had something vaguely related:
>
> http://south.readthedocs.org/en/latest/tutorial/part3.html
>
> However, the command did not make it over to built-in migrations.
>
> On Monday, November 30, 2015 at 8:44:37 AM UTC-5, Shai Berger wrote:
>>
>> Hello,
>>
>> Part of my work lately was to help bring a large, complex project from
>> Django
>> 1.7 to 1.8. This effort was being done in parallel to continued
>> development of
>> the project, in a separate branch. To make things more fun, the project
>> uses
>> UUID fields for PKs in many models; on 1.7, this was done with
>> django-uuidfield,
>> but of course, with 1.8 we changed this to models.UUIDField. As a result,
>> many
>> apps have migrations for moving to 1.8 (there are also a few more for
>> EmailField's etc).
>>
>> I found myself, several times, getting new migrations in an app where
>> I've
>> already added the 1.8-related migrations. When this happened, what I'd
>> like to
>> do is "rebase" the migration -- undo it, delete it, and recreate it on
>> top of
>> the newly-added migrations.
>>
>> However, doing that turned out hard. Not only is there no single
>> operation for
>> it, I couldn't even do the parts easily -- I could neither undo the
>> migration
>> nor even fake it out, because the migration folder was in a "merge
>> conflict"
>> state (more than one final migration).
>>
>> A rebasemigration command would be wonderful. But the building block for
>> it --
>> the ability to undo a single migration, even when a conflicting one has
>> been
>> added to the tree, seems both more essential and easier to do.
>>
>> Thoughts?
>>
>> Thanks,
>> 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/77b63ad8-a16b-4ba3-bf3a-3ae5885f85e5%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/CAFwN1ursOEwS4CJeH%2Bw%3DgtVFUY-BV11utnUtbkE0K8mFrFhsOw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration "rebase", or just an "undo" that works with conflicts

[Silvio]

I've had this situation come up too. It would indeed be very useful.

Django South had something vaguely related:

http://south.readthedocs.org/en/latest/tutorial/part3.html

However, the command did not make it over to built-in migrations.

On Monday, November 30, 2015 at 8:44:37 AM UTC-5, Shai Berger wrote:
>
> Hello, 
>
> Part of my work lately was to help bring a large, complex project from 
> Django 
> 1.7 to 1.8. This effort was being done in parallel to continued 
> development of 
> the project, in a separate branch. To make things more fun, the project 
> uses 
> UUID fields for PKs in many models; on 1.7, this was done with 
> django-uuidfield, 
> but of course, with 1.8 we changed this to models.UUIDField. As a result, 
> many 
> apps have migrations for moving to 1.8 (there are also a few more for 
> EmailField's etc). 
>
> I found myself, several times, getting new migrations in an app where I've 
> already added the 1.8-related migrations. When this happened, what I'd 
> like to 
> do is "rebase" the migration -- undo it, delete it, and recreate it on top 
> of 
> the newly-added migrations. 
>
> However, doing that turned out hard. Not only is there no single operation 
> for 
> it, I couldn't even do the parts easily -- I could neither undo the 
> migration 
> nor even fake it out, because the migration folder was in a "merge 
> conflict" 
> state (more than one final migration). 
>
> A rebasemigration command would be wonderful. But the building block for 
> it -- 
> the ability to undo a single migration, even when a conflicting one has 
> been 
> added to the tree, seems both more essential and easier to do. 
>
> Thoughts? 
>
> Thanks, 
> 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/77b63ad8-a16b-4ba3-bf3a-3ae5885f85e5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: status of 1.9 release blockers

[Tim Graham]

We're on schedule for 1.9 final tomorrow. There are 3 release blockers in 
Trac, however, 1 blocker affects only master and the other two also affect 
1.8 and thus aren't blockers for 1.9.

On Saturday, November 14, 2015 at 3:17:27 PM UTC-5, Tim Graham wrote:
>
> Sorry for the lack of updates, but no news is good news. We're on track 
> for a release candidate on Monday.
>
> On Saturday, October 17, 2015 at 7:41:55 PM UTC-4, Tim Graham wrote:
>>
>> We're on schedule for Monday's beta release. Most of the backported fixes 
>> have been issues affecting 1.8 too.
>>
>> On Saturday, October 3, 2015 at 10:31:13 AM UTC-4, Tim Graham wrote:
>>>
>>> We've resolved a couple of release blockers on the stable/1.9.x branch 
>>> since the alpha, but overall bug reports have been quiet. Hopefully that's 
>>> a good sign!
>>>
>>> The beta release is scheduled for 2 weeks + 2 days from now, Monday 
>>> October 19.
>>>
>>> On Wednesday, September 23, 2015 at 3:17:28 PM UTC-4, Tim Graham wrote:

 All known issues are resolved. I plan to create the branch and make the 
 release in about 4 hours if nothing else pops up.

 On Wednesday, September 23, 2015 at 9:46:40 AM UTC-4, Tim Graham wrote:
>
> I'm okay with deferring it. I'll see if we can release the alpha later 
> today then. I found one regression in the unreviewed ticket queue this 
> morning and submitted a pull request. I'm also investigating a possible 
> regression causing the djangoproject.com tests to fail.
>
> On Wednesday, September 23, 2015 at 6:39:58 AM UTC-4, Markus 
> Holtermann wrote:
>>
>> I did not fully follow the discussion, but by the amount of email 
>> notifications I got on that PR if feels to me that deferring it to 1.10 
>> would be the better option, also considering what Tom said about this 
>> being 
>> part of a core component and it has to be done right.
>>
>> /Markus
>>
>> On Wednesday, September 23, 2015 at 2:54:50 AM UTC+10, Tim Graham 
>> wrote:
>>>
>>> The second patch has been committed, and the first one is still 
>>> under review. 
>>>
>>> Florian says "with all that forth and back [on the pull request] I 
>>> am not sure if it is not better to defer it to 1.10, i.e. I completely 
>>> missed the base64 stuff for instance. One option would be to ship 
>>> it with the feature inactive and mark it as experimental and ask users 
>>> to 
>>> try it out. Though, that would probably be a first."
>>>
>>> I'd also be more comfortable if it were disabled by default. The 
>>> main problem for me is the documentation doesn't really motivate the 
>>> feature very well and describe how one should go about setting the 
>>> values 
>>> of the new settings.
>>>
>>> Options:
>>> 1) Defer the patch to 1.10 and release the alpha today.
>>> 2) Maintain the feature freeze until the end of the week to see if 
>>> the patch is better resolved by then (fix bugs on master in the 
>>> meantime) 
>>> and release the alpha then (whether or not the patch is completed).
>>> 3) Create the 1.9 branch today to allow normal development to 
>>> proceed on master and release the alpha by the end of the week with the 
>>> option to backport the patch if it's completed.
>>>
>>> Opinions?
>>>
>>> On Monday, September 21, 2015 at 9:08:22 PM UTC-4, Tim Graham wrote:

 Let's consider master feature frozen for now. There are two more 
 patches I'd like to merge before we cut the 1.9 branch.

 #21231 -- Enforced a max size for POST values read into memory
 https://github.com/django/django/pull/3852
 Status: Needs final code reviews and probably some doc enhancements 
 (docs could possibly be deferred until after alpha). Florian & Shai, 
 as 
 you've been taking the lead on reviewing this, please let us know your 
 thoughts.

 #24509 -- Added Expression support to SQLInsertCompiler
 https://github.com/django/django/pull/5324 
 Status: Josh working on some doc enhancements now, I will review in 
 the morning.

 On Friday, September 18, 2015 at 10:03:45 AM UTC-4, Marc Tamlyn 
 wrote:
>
> Sorry everyone :(
>
> On 18 September 2015 at 15:01, Tim Graham  
> wrote:
>
>> The major features are officially deferred. Let's try for the 
>> feature freeze by end of day on Monday and the alpha release on 
>> Tuesday.
>>
>> There aren't any critical blockers at this time. Jani hasn't 
>> completed the Oracle GIS work, but this isn't a must-have for alpha.
>>
>>
>> On Saturday, September 12, 2015 at 7:50:31 PM UTC-4, Tim Graham 
>> wrote:
>>>
>>> With 1 week to go until 

Re: 1.8 shipping invalid .py files in the startapp template

[Florian Apolloner]

On Monday, November 30, 2015 at 7:02:05 PM UTC+1, Tim Graham wrote:
>
> Florian, your preference is to decline the change proposed by Chris and 
> just deal with any support queries when people see a log like below? I 
> understand it's not ideal to add workarounds for bugs in other software as 
> the proposal does, but it seems like a pragmatic solution to me.
>

I am not against including it, but depending on how packaging works in 
Debian it could be possible to call pycompile with a proper exclusion list 
instead. The PR itself only works by accident, there are also files in 
project_template (namely the settings file and urls) which also should not 
get compiled (even if they are valid). So if you want to include the PR, 
please make sure it properly works for __all__ package data, not just the 
one with invalid data.

That said, the amount of issues I have seen in #django due to the 
debundling of pip in debian/ubuntu is not something I can count on one hand 
anymore. Most of the time I just gave up and suggested to install pip 
manually, all problems gone. The syntax error has popped up three times so 
far (iirc) and requires no fixing aside from educating people.

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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3ed86d2e-a6a0-462f-90a9-dad59d9f70b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.8 shipping invalid .py files in the startapp template

[Tim Graham]

Actually, the SyntaxError issue isn't related to pip but to setuptools 5.5 
and 5.5.1 (Debian stable ships the latter).

Florian, your preference is to decline the change proposed by Chris and 
just deal with any support queries when people see a log like below? I 
understand it's not ideal to add workarounds for bugs in other software as 
the proposal does, but it seems like a pragmatic solution to me.

$ pip install Django==1.9c2
Downloading/unpacking Django==1.9c2
  Downloading Django-1.9rc2-py2.py3-none-any.whl (6.4MB): 6.4MB downloaded
Installing collected packages: Django
  Found existing installation: Django 1.9c1
Uninstalling Django:
  Successfully uninstalled Django
Compiling 
/home/tim/.virtualenvs/tmp-65a61cac481337a0/build/Django/django/conf/app_template/apps.py
 
...
  File 
"/home/tim/.virtualenvs/tmp-65a61cac481337a0/build/Django/django/conf/app_template/apps.py",
 
line 4
class {{ camel_case_app_name }}Config(AppConfig):
  ^
SyntaxError: invalid syntax

Compiling 
/home/tim/.virtualenvs/tmp-65a61cac481337a0/build/Django/django/conf/app_template/models.py
 
...
  File 
"/home/tim/.virtualenvs/tmp-65a61cac481337a0/build/Django/django/conf/app_template/models.py",
 
line 1
{{ unicode_literals }}from django.db import models
 ^
SyntaxError: invalid syntax

Successfully installed Django
Cleaning up...

On Saturday, November 28, 2015 at 8:47:13 PM UTC-5, Florian Apolloner wrote:
>
> Damn, I meant to write "and not real packages"
>
> On Sunday, November 29, 2015 at 2:46:22 AM UTC+1, Florian Apolloner wrote:
>>
>>
>>
>> On Saturday, November 28, 2015 at 7:16:10 PM UTC+1, lamby wrote:
>>>
>>> > at least project_template would be missing etc
>>>
>>> Deliberately so; these are not invalid .py files.
>>>
>>
>> Yes, but by luck and/or accident. In the end they are still package data 
>> and real packages, so you should never run pycompile on them in the first 
>> place. 
>>
>

-- 
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/a2353277-0b8b-4d64-8ef0-661afeecfdf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Migration "rebase", or just an "undo" that works with conflicts

[Shai Berger]

Hello,

Part of my work lately was to help bring a large, complex project from Django 
1.7 to 1.8. This effort was being done in parallel to continued development of 
the project, in a separate branch. To make things more fun, the project uses 
UUID fields for PKs in many models; on 1.7, this was done with 
django-uuidfield, 
but of course, with 1.8 we changed this to models.UUIDField. As a result, many 
apps have migrations for moving to 1.8 (there are also a few more for 
EmailField's etc).

I found myself, several times, getting new migrations in an app where I've 
already added the 1.8-related migrations. When this happened, what I'd like to 
do is "rebase" the migration -- undo it, delete it, and recreate it on top of 
the newly-added migrations.

However, doing that turned out hard. Not only is there no single operation for 
it, I couldn't even do the parts easily -- I could neither undo the migration 
nor even fake it out, because the migration folder was in a "merge conflict" 
state (more than one final migration).

A rebasemigration command would be wonderful. But the building block for it -- 
the ability to undo a single migration, even when a conflicting one has been 
added to the tree, seems both more essential and easier to do.

Thoughts?

Thanks, 
Shai.

Re: Fellow Report - November 28, 2015

[Tom Christie]

Hi Edwar,

Commenting on the ticket itself would be more appropriate. Also note 
that the ticket's only been open 5 days - I'd suggest a little more 
patience might be needed :)

  T.

-- 
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/3c0b854e-7caa-4540-aa64-056fe4115f59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.