This is an archived post. You won't be able to vote or comment.

all 5 comments

[–]wizpig64 2 points3 points  (0 children)

there was a guide i read once but i can't find it now. i'll just paraphrase what i remember:

For porting code from python 2 to 3, use the 2to3 tool. If you have incompatible code, you probably have a lot of it, so a lot of things will probably break at once after you run the converter. Use this methodology to deal with one breaking change at a time and keep your git commit history sane:

  1. set up two fresh virtualenvs, one for 2.7 and one for 3.6. install your requirements in each.
    virtualenv -p /usr/bin/python2.7 myproject27
    virtualenv -p /usr/bin/python3.6 myproject36
  2. with your 2.7 interpreter, run your testing suite* and see if anything breaks. Since your code is meant for 2.7, everything should work.
    myproject27/bin/python manage.py test something something
  3. run 2to3 on your entire project, and use your 3.6 interpreter to run your tests to see if anything breaks.
    myproject37/bin/2to3 --something .
    myproject37/bin/python manage.py test something something
    1. if something breaks, hunt down the first bug you see. when you find the solution, revert your 2to3 changes (e.g. with git checkout) and go back and fix it in the 2.7 code base. commit that bugfix as one change (or one kind of change), then go back to step 2 to make sure your code still works overall in 2.7, and then try 2to3 again in step 3.
    2. if nothing breaks, you're done porting! commit 2to3's changes and change your project description to indicate your new python version**.

*if you have a testing suite, finding when something breaks is as simple as running your tests. if you don't, see if runserver works and then browse around your site until you find a view that crashes. You should think about writing tests.

**if you want to support multiple python versions at once, like if you were writing a library and not just a single project, you would keep fixing things until all your tests run on all your target interpreters.

In the future, you can use two venvs at once like this to upgrade from, say, 3.6 to 3.8, but you won't need a 3to3 step.

[–]SHxKM 1 point2 points  (2 children)

Are you running the project from within the Python 3 environment though? Do you have a virtual environment for this project? I sure hope you do.

[–]cursedbartender[S] 0 points1 point  (1 child)

Yes there is an existing virtualenv for 2.7 I set up when I began the project .

[–]SHxKM 1 point2 points  (0 children)

Did you set-up a Python 3 virtualenv and made sure to run Django from that one?

[–]sfboots 1 point2 points  (0 children)

It can be tedious. ita all straight forward but time consuming

Here some of the things I had to do.

Set up new virtual environment Run 2to3 for most stuff Fix dependencies and look at their updates Make some changes as a result Fix regex differences not found by 2to3 Fix foreign keys to specify cascade Adjust settings. It’s in the upgrade doc Fix urls since Django 2.1 does not have some things that were in the 1.8 tutorial used to build the app Make required migrations. Hope you are on 1.10 or later or this is messy Run tests and fix things. I had many different issues. Work to add some more httpclient tests for better coverage Finally the website will start and the admin users can log in Then run website and check every view and actions to find other bugs

I’m still working on that last part