Re: [Ranger-users] let's discuss commands.py

[Miodrag Milic]

What do you think about removing copy-all option completely and use "imports" at the end of those 4 files that will call adequate files from ~/.config/ranger folder. Those files should be empty initially.

So user config/code will be separated from default config/code, and updates will sometimes require some tweaks to user files when compatibility breaks which could be announced at ranger startup as an warning.

You could even provide soft links to those 4 "default config" files along which will serve only for easy of access. 

This is IMO better then doing all kinds of mumbo jumbo to hide internals. 

I personally do not worry about compatibility breaks. Its more job on my side but thats the cost of the progress and code purity. Also, ranger is probably not something that will be used a lot in enterprise environments where compatibility is critical (and if you do, you can always not upgrade).

On Wed, Feb 27, 2013 at 6:50 PM, Roman Z. <address@hidden> wrote:

In trying to keep things compatible between ranger versions and still
giving you much power through configuration files, I already moved from
apps.py to rifle.conf which is completely independent of ranger
internals, removed options.py and used an independent shell script for
generating previews.  Also, configs are compatible between releases with
the same major and minor version number.

Currently the config files are:

1. rc.conf     - no python, but relies on syntax of commands and on
                 commands.py to work properly
2. commands.py - relies heavily on ranger internals
3. rifle.conf  - independent
4. scope.sh    - independent

And there you see the problem that I want to talk about.  rc.conf
contains a list of ranger commands, so it relies on commands.py. But
commands.py works only if the user keeps it up to date.  If the user
does --copy-config=all and upgrades from ranger 1.5.* to ranger 1.6.0,
his commands will do wrong things.

A possible solution would be to remove system commands like "set",
"alias", "*map" from commands.py so the user won't overwrite them.
Maybe we can put them in a separate file, or in a part of commands.py
that is stripped off or commented out when using --copy-config.

Another would be to skip copying "commands.py" entirely when using
--copy-config=all, since the majority of the users don't care about
commands.py anyway.  One could still get it with --copy-config=commands.

Another way would be to make the commands bare-boned stubs which mostly
call API functions.  But would this reduce the use of the config file?

Maybe we could even remove the commands.py completely.  To be honest, my
commands.py is empty, since you can do a lot through rc.conf already.

I don't know.  What is your take on this?  Any other compatibility
issues you're worried about?

Roman