Add installation method

[parmort]

This creates a more user-friendly and (hopefully) future-thinking installation method. As more complicated colorschemes pop up, #2 for instance, this will become crucial, as managing multiple files quickly becomes a nightmare.

Advantages

• Adds easy installation for colorschemes with plugin files too
• Symlinks are used to preserve the ease to update
• A copy option lets users copy the files if they wish

Disadvantages

• Adds one more step to the process.
• The command must be prefaced with python. I couldn't get the executable attribute to work right.

Other Changes

• Add the .flake8 and .pylintrc from ranger, to keep code styles consistent

[toonn]

I'm not closing this because I would like to discuss how we structure the repo and the instructions. However, I'm not convinced this is better.

First of all, a makefile seems more suitable for this job. Comes with lots of bonus features like not doing anything that's already been done if you invoke it again. Custom code that achieves the same thing is an added maintenance burden.

Why I'm reluctant

Currently all people have to do is clone the repo into ~/.config/ranger, it doesn't get much simpler than that imo. If we replace this with anything it should at the very least not be much more work.

Note that I'm not saying your approach is much more work. But it's multiple commands instead of one command and it'll require a much more complicated repository layout.

Further discussion in #5 because issues are more visible than PRs.

[parmort]

Fair. I agree it's a big change and kind of bloated. However, this way it's easier for people to install multi-file schemes (although I do note #5) by just running one more command.

You also mention in #5 that the ranger team should not be responsible for maintaining schemes, which I agree with. A makefile (an approach I did consider) would make it harder, if only slightly, for people to add schemes, not to mention that it's one more thing to think about. Plus, if the team decided to change how custom files were organized, or even how the folders are named, we would have to change the entire makefile (which may or may not be large, depending on how many people PR their schemes).

So, in other words, both of us might not be right, but I would personally not use makefiles because of the lack of scalability included. And, if the repo gets more schemes, it will be an even harder decision to make then.

[toonn]

I'm not sure why you think makefile's aren't suited to this. They are pretty flexible. You wouldn't have to hardcode a single theme, just the different ways a theme might have to be installed. For instance you'd just link every top level file and for subdirs you link all the files in each of the subsubdirs into the approriate place in ~/.config/ranger.

I don't see how a python script would handle changes to the organization of the repository any better?

Whatever solution we go with, the ranger team should be responsible for its maintenance imo. (Note that I"m talking about the installation scripts provided with the repo, not the colorschemes in the repo.) The installation scripts are closely tied to ranger's implementation so if we were to overhaul the colorschemes implementation it's not fair to put the burden of porting them on the subset of the community that's probably mostly just interested in colorschemes.