Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare for Django 2.0 #320

Closed
wants to merge 17 commits into from
Closed

Prepare for Django 2.0 #320

wants to merge 17 commits into from

Conversation

flesser
Copy link

@flesser flesser commented Oct 20, 2017

I was trying to get django-simple-history working with Django 2.0.
Here are the changes I made to get it run. (No guarantee for completeness or correct downward compatibility)

`field.rel.to` was deprecated since 1.9 and removed in 2.0
`django.core.urlresolvers` was deprecated since 1.10 and removed in 2.0
see https://docs.djangoproject.com/en/1.11/ref/urlresolvers/
@codecov-io
Copy link

codecov-io commented Oct 20, 2017

Codecov Report

Merging #320 into master will decrease coverage by 0.59%.
The diff coverage is 78.26%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master     #320     +/-   ##
=========================================
- Coverage   97.63%   97.04%   -0.6%     
=========================================
  Files          15       15             
  Lines         593      609     +16     
  Branches       73       74      +1     
=========================================
+ Hits          579      591     +12     
- Misses          7       10      +3     
- Partials        7        8      +1
Impacted Files Coverage Δ
...istory/registry_tests/migration_test_app/models.py 100% <100%> (ø) ⬆️
simple_history/admin.py 98.09% <100%> (+0.05%) ⬆️
simple_history/models.py 95.16% <72.22%> (-1.74%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35febc3...c8e09e8. Read the comment docs.

@@ -173,7 +173,8 @@ def copy_fields(self, model):
if getattr(old_field, 'db_column', None):
field_arguments['db_column'] = old_field.db_column
field = FieldType(
old_field.rel.to,
# required for Django <= 1.8 # required for Django >= 2.0
old_field.rel.to if hasattr(old_field, 'rel') else old_field.remote_field.model,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having this inline makes for a dense line IMHO.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest, for readability

if hasattr(old_field, 'rel'):
    target = old_field.rel.to  # Django <= 1.8 
else:
    target = old_field.remote_field.model # Django >= 2.0
field = FieldType(target,
    ...

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could even be determined just once and saved (in this module before this class, or in a shared compat module).

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also I think the test should be for the new attribute name; both exists in django 1.11 but the old-style one causes a warning.

if self.thread.request.user.is_authenticated():
try:
# Django < 1.10
is_authenticated = self.thread.request.user.is_authenticated()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will work but emit warnings in 1.10+

@hangya hangya mentioned this pull request Dec 3, 2017
except AttributeError:
return None
if not is_authenticated in (True, False):
is_authenticated = is_authenticated() # Django < 1.10
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is not correct. In 1.10 or 1.11, is_authenticated is an instance of CallableTrue or CallableFalse, not True or False, so the if not in test will fail and go into line 283 which will raise the deprecation warning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that might be. I tested it having the callable boolean in mind but now I saw that none of the implemented tests get to this line at all in Django 1.10+ (because self.thread.request.user.is_authenticated raises the caught AttributeError.

request.user raises an AttributeError in multiple tests in Django 2.0 (AttributeError: 'WSGIRequest' object has no attribute 'user'). For that reason it might be the next step to fix those.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This error might be caused by a wrong ordering of middleware.

url(r'^admin/', include(admin.site.urls)),
url(r'^other-admin/', include(other_admin.site.urls)),
url(r'^admin/', admin.site.urls),
url(r'^other-admin/', other_admin.site.urls),

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the omission of function include backwards compatible? All other edits seem backwards compatibility except maybe this one.

Copy link
Contributor

@dgilge dgilge Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests passed using tox.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect.

@RossRogers
Copy link

@treyhunner , @macro1 ,

If you simply inspect this pull's edits, they are, at the very least, non-destructive and backwards compatible to my eyes. Any chance of merging this pull request and releasing django-simple-history ?

@merwok
Copy link

merwok commented Dec 20, 2017

PR has a conflict to resolve before it can be merged.

@RossRogers
Copy link

RossRogers commented Dec 20, 2017

Ok. I forked @treyhunner's repor and pulled in @flesser 's repo here https://github.com/RossRogers/django-simple-history . This is my merge resolution for the only merge conflict:

-                 if isinstance(old_field.rel.to, str) and old_field.rel.to == 'self':
++                
++                #           required for Django <= 1.8                       # required for Django >= 2.0
++                object_to = old_field.rel.to if hasattr(old_field, 'rel') else old_field.remote_field.model
++                if isinstance(object_to, str) and object_to == 'self':
 +                    object_to = old_field.model
-                 else:
-                     object_to = old_field.rel.to

@treyhunner , @macro1 ,

Do you want me to create another pull request, superseding this one?

Copy link

@cgthayer cgthayer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for fixing this! Looking forward to being able to use Django 2.0

@@ -179,7 +179,8 @@ def copy_fields(self, model):
if isinstance(old_field.rel.to, str) and old_field.rel.to == 'self':
object_to = old_field.model
else:
object_to = old_field.rel.to
# required for Django <= 1.8 # required for Django >= 2.0

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor: doubled up comment

@@ -179,7 +179,8 @@ def copy_fields(self, model):
if isinstance(old_field.rel.to, str) and old_field.rel.to == 'self':
object_to = old_field.model
else:
object_to = old_field.rel.to
# required for Django <= 1.8 # required for Django >= 2.0
object_to = old_field.rel.to if hasattr(old_field, 'rel') else old_field.remote_field.model
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As said before, this is the wrong order to avoid warnings.

Line 179 seems to have the same problem.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, you want to see
old_field.remote_field.model if hasattr(old_field, 'remote_field') else old_field.rel.to
?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did that edit plus helped out @flesser 's merge to guard new uses of old_field.rel.to here https://github.com/flesser/django-simple-history/pull/4 .

Ross Rogers and others added 2 commits December 21, 2017 10:12
Correct merge to remove new uses of `old_field.rel.to`.  Reorder field check per @merwok feedback
@RossRogers
Copy link

RossRogers commented Jan 24, 2018

Well... I'm trying to do the migration, but having trouble with tests, code coverage, and environments. My codebase is running fine against this version, but I have a niche use case where I use it to talk to IBM's DB2, and antique windows SQL Server instances from the turn of the millenia:

https://github.com/RossRogers/django-pyodbc

You can install with

pip install git+ssh://git@github.com/RossRogers/django-pyodbc@master

So, I'm in the middle of doing the upgrade to django 2.0 myself and then I want to create a new django 2.0 branch and upgrade the major version to 2, get code coverage up, create release candidates for the pip system et c. Anyways, still a work in progress, but you're welcome to try the version I'm using. May want to fork it though, as I need to move those edits to a new branch. My repo is a bit of a scratch repo...

@Rested
Copy link

Rested commented Jan 25, 2018

@RossRogers Right, im currently using your https://github.com/RossRogers/django-simple-history/archive/django2.0.zip#egg=django-simple-history and it seems to be working. Would just be great if this could be merged and pushed to pip. What is blocking that at the moment @merwok ? Coverage?

@merwok
Copy link

merwok commented Jan 25, 2018

I’m not in a position to block a PR in this repo, just making comments since I’m also using django-simple-history :)

My comments were about wrong code for is_authenticated (would still raise warnings as is since that attribute won’t be True/False but a CallableTrue/CallableFalse) and code style (the repeated super long lines for the related attributes).

@RossRogers
Copy link

Oh my goodness. I was commenting in the repository. I've been trying to migrate django-pyodbc. Apologies.

@ransford
Copy link

ransford commented Feb 7, 2018

Hi! My little group of django-simple-history fans can offer to help here if the tasks are well defined, such as writing new tests to increase coverage. Is that the only thing remaining before this is merged, or do the is_authenticated issues @dgilge and @merwok raised need to be addressed via code fixes, too?

@RossRogers
Copy link

If I may be so presumptuous, I think activity from the maintainers/committers is kinda what's missing. If so, I totally get that life happens.

@ransford
Copy link

ransford commented Feb 8, 2018

Sorry @RossRogers, I assumed you were a maintainer because of the diligent work you already put in -- hat tip to you.

@pikrzysztof
Copy link

Can someone comment on branch-20 health and which commits are best to use?

@RossRogers
Copy link

@pikrzysztof , all the edits are necessary... If you look, there are not many file diffs. Most of the edits come from pulling from the master repository and doing an automerge. Anyways, I'm using my clone in production and I haven't had any problems, yet..

 pip install -U git+ssh://git@github.com/RossRogers/django-simple-history@django2.0

@jhrr
Copy link

jhrr commented Feb 9, 2018

Prob needs to be pip install -e git+https://git@github.com/RossRogers/django-simple-history@django2.0#egg=django_simple_history though.

@RossRogers
Copy link

RossRogers commented Feb 9, 2018

Maybe that works too, but I've installed it with that other command successfully in 3 different virtualenvs, both dev and production.

@jhrr
Copy link

jhrr commented Feb 9, 2018

I don't think it will work for other people as they don't share your ssh credentials.

@RossRogers
Copy link

The repo is wide open to reads, including using your credentials, but ok, if you don't have ssh credentials for your account on your github account, then it will fail that ssh command. Anyways, [unfortunately] many ways to skin a cat in git.

@jhrr
Copy link

jhrr commented Feb 9, 2018

I do have ssh creds for my account and your command did fail with permission denied.

@RossRogers
Copy link

Okey doke.

@Rested
Copy link

Rested commented Feb 9, 2018 via email

@KevinGrahamFoster
Copy link
Contributor

I'm available to help make this PR a released reality too if someone gives some direction in what's required both from a code standpoint and for the two failing checks. It appears to just be too big of a diff in coverage, suggesting that we should add more coverage tests. Can someone confirm that?

@mattLLVW
Copy link

Any update on this release?

@merwok
Copy link

merwok commented Mar 15, 2018

I don’t know if codecov supports combining the coverage data from multiple runs. With compat branches, you have to run tests with different Python and Django versions to go into all branches.

tox and coverage.py make it pretty easy to do that locally, but I don’t know how much control Travis / Codecov give you here.

@macro1
Copy link
Collaborator

macro1 commented Mar 18, 2018

@merwok the tests were not actually running against Django 2.0. I opened a new PR just now that does have the test changes as well (#353)

@macro1
Copy link
Collaborator

macro1 commented Mar 18, 2018

Interesting... Apparently Github will combine upstream changes to a downstream branch in a PR

@rossmechanic
Copy link
Collaborator

Merged necessary changes into master. Support for Django2.0 should now work on master. Will release soon. Added the authors here into AUTHORS.rst to give you al credit

@dgilge
Copy link
Contributor

dgilge commented Apr 6, 2018

Great! Thanks for maintaining this valuable package!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet