Code refactor and cleanup

[alexandrevicenzi]

I noticed that many places could make use of some code cleanup and small refactor. This usually does not affect anything but makes the code more readable.

What I noticed:

• Not following PEP8 in some places
• PyLint or any other tool will raise many warnings about code standards
• Splitting API (#134) was not a good idea, code is duplicated, no Docker for api-video

What I propose:

• Fix PEP8 and PyLint issues
• Enable Black or PyLint to enforce code standards by running Travis CI on each PR
• Make one single API with multiple endpoints, it's just easy to maintain the code

If this is a good idea I'll start sending patches.

[jantic]

• PEP8/PyLint issues: Totally go for it. These primarily stem from a combination of trying to stick with FastAI conventions (which don't conform 100%) and me being relatively new to Python and/or being in a hurry. None of it's justified, basically- even FastAI conventions. I've changed my mind on that. No need for that anymore.
• Enabling Black or Pylint + TravisCI: That sounds awesome. If you're up for that, please do!
• Splitting API not being a good idea: That one I'm just not sure about what should be done yet. I'm definitely not a fan of duplicated code for the most part so that should be addressed for sure. But I'm not sure what exactly motivated the splitting of the API (you'll want to ask the original author for that one). Honestly I don't use any of that code and don't pay much attention to it- that's being developed for use over at OVH.

I'm a fan of your work so far so please, go ahead and do your thing!

[jqueguiner]

Thé split of API is due to overload of gpu. When having the 2 APIs in the same place the load into GPU being done at the main is allocating a lot of gpu memory which can result in lack of memory of you are ruining this on a small gpu.

[jqueguiner]

That being said I am ok to reverse this stuff

[alexandrevicenzi]

@jantic @jqueguiner what if we get rid of everything that is not DeOldify (code + notebooks) itself from this repo?

The idea would be making DeOldify a library, pip installable. For example pip install DeOldify. Everything else, API, apps, go to a spare repo, maybe DeOldifyApp, or any other name.

I believe that this would make more sense as @jantic is not interested in this part.

Also, thinking this way, what if someone wants an Android app, would it fit this repo? Of course not. So, the API might not be in this repo as well.

Making DeOldify a true python lib open new possibilities for a lot of extensions, like APIs, command-line tool, maybe even a desktop app.

[jqueguiner]

Personally I really love the idea but it’s up to Jason to decide !

[jantic]

@alexandrevicenzi @jqueguiner I'm totally in support of this. I personally can't devote much if anytime to this sort of overhaul at this point so this would be something I'd have to trust you with. It'd make sense to grant collaborator status if you're doing something of this magnitude. Just let me know if you want that. I'll still want to do code review and etc but really- I'm prepared to give you the keys and let you do what you think is right.

[alexandrevicenzi]

@jantic about the library I can do that, I have some projects on PyPI and I do similar work on my job as well.

Collaborator access would be great, I would never merge to master directly but you can force master protection on GitHub, so no one will merge to master, unless they are admins.

You may ask why I'm doing this, the main reason now is because I don't have a suitable graphics card to train the network and play with, but I really like this project.

[jantic]

@alexandrevicenzi Great idea on the master protection. I've put that in place. Collaborator invite is sent!

[alexandrevicenzi]

@jantic Thanks.

[jantic]

Going to close this as work, was done on this already.