jedburke / lemony Goto Github PK

As safety is imperative, Lemony could keep track of the files it renames in the event the user incorrectly renames a set of files. With the list of files it renamed and their original names, the script will be able to 'revoke' the rename.

The data may be stored in a JSON formatted document for perpetual use. Size may however become an issue as the script is used. As with logs, the renaming history may be split into days and cleared after X days. While not necessarily for users, the structure of the file itself needs to be simple and uncluttered.

Consider:
> lemony rename "path/to/ecchi/pictures" --revoke

A switch called revoke is added to the rename subparser. The files in the directory passed will be queried against the history file and renamed accordingly.

The dry run switch must be available. Being able to specify which files rename are to be revoked should be present as well.

> lemony revoke "path/to/ecchi/pictures/" --file "best_ecchi_pic.jpg;second_best_ecchi_pic.jpg" --prompt

In this example, revoke becomes a subparser as apposed to a switch on the rename subparser. It accepts a directory like rename. If the file argument is omitted, all files are processed. The names specified in file are the current names. The prompt switch presents a [Y/N] option for each reversion.

The idea is still squishy, so the implementation may be a little ways away.

Doing so will allow for plugins or other methods to short-circuit the renaming. For example, a liquid-style syntax could be implemented and be decoupled from the main renaming methods.

Make sure new and existing code conforms to Python coding conventions, specifically PEP8.

Remove clutter from the readme file by moving all but the bare essential commands and particulars to the wiki. New users should get a feel for the project and the way it goes about things without being overwhelmed with all of its details.

The switches currently related to the rename operation must be moved to the "rename" sub-parser.

Current way:

lemony "path/to/ecchi/pics"

New way:

lemony rename "/path/to/ecchi/pics"

Doing so will allow for opportunities at larger functionality without cluttering the parser with options.

Log the function calls to better understand went wrong with the script and caused unexpected behavior. If possible, the logs need to be simple for non-technical users to be able to read and understand it themselves, yet provide enough information and to be useful to technical user.

Allow users to specify directories with globbing syntax.

> lemony "path/to/ecchi/**/*"

Result:
path/to/ecchi/pics/{files}
path/to/ecchi/vids/{files}

When setting the directory in the profile, users should have the choice to set the directory as a string literal and not an array.

Current

    directory: ["path/to/ecchi/pics"]

Proposed:

    directory: "path/to/ecchi/pics"

The same will go for extensions and everything else which accepts an array which the user supplies and may only have one element. Being able to pass an array of directories and file extensions will obviously remain, however the user will not be forced into specifying them when unnecessary.

Write and document unit tests for each of the existing classes.

Restructure Lemony's arguments (rename etc) into plug-ins which load when it starts. Doing so will allow arguments to be added or removed in a simpler manner without affecting the core of the project.

Document all new and existing classes and functions.

Modularize the code into components which may be easily tested and re-used.