Add Multiple Tag Searches Connected via Logical OR

[9-FS]

Add support for multiple tag searches connected via logical OR in a user friendly way. This could be done by re-defining NHENTAI_TAGS to a Vec<Vec<String>>, but I don't find it user friendly enough to use. It would also destroy any possibility to set NHENTAI_TAGS via docker-compose.yaml.

To properly support this and even more complex searches down the line, I'm currently thinking that implementing a graphical user interface might be necessary. I like to avoid that for several reasons: I don't have the time, I don't have the experience, and I'm worried about multi platform support.

[9-FS]

The current workaround is to have multiple docker-compose.yaml each defining a different search by defining NHENTAI_TAGS in their environment section and then playing round robin with the container that is being used.

[psilabs-dev]

I suggest a file configuration like "downloadme.txt" but instead each line is a logical AND connection,

# jobs.txt

key-1:"value-1", key-2:"value-2"
key-3:"value-3"
key-4:"value-4"

So the program reads jobs.txt, splits it by line, goes line by line and treating each line as a NHENTAI_TAGS. I think this would minimize refactoring needed and not require a GUI.

As for more complicated examples maybe a json approach, you might look at elasticsearch query dsl, but I personally think it would be overkill and go beyond nhentai's own search ability.

I'd contribute if I knew a bit more about Rust, sorry. Love this project <3

[9-FS]

How do you suggest should this be compatible with docker compose?

[psilabs-dev]

There should be no change to the docker compose. Add a file in config,

/app/config/jobs.txt

If you want, you can also add an environment variable JOBS_FILEPATH=./config/jobs.txt, if this should be somewhere else.

So you can do something like

jobs_filepath = os.getenv("JOBS_FILEPATH", "./config/jobs.txt")
if os.path.exists(jobs_filepath):
    with open(jobs_filepath, "r") as reader:
        nh_tags_list = reader.readlines()
        for nh_tags in nh_tags_list:
            try:
                process_nh_tags(nh_tags) # since this logic already exists.
            except:
                ...

Then there are these archival strategies (determine priority, what takes precedence etc):

• running program as is
• download by DOWNLOADME_FILEPATH
• download by NHENTAI_TAGS
• download by JOBS_FILEPATH

[9-FS]

This solution seems pretty janky. I'm not going to add another archival strategy unless I really have to.

Acceptable solutions that I can think of currently are

• a graphical user interface (not gonna happen)
• change configuration file format from TOML to YAML and use a 2 dimensional array to save multiple tag searches

I consider using a 2 dimensional array in YAML user-friendly enough because it natively supports nested array structures with minimal syntax.

Problem with the YAML solution I currently see is that docker compose does not natively support environmental variables of type array. Changing NHENTAI_TAGS from a 1 dimensional array to a 2 dimensional array would make things even more complicated to use with docker.

The tradeoff could be worth though considering setting NHENTAI_TAGS from the docker-compose.yaml will probably be less required if logical OR can be used from within the config file. Hmm

[psilabs-dev]

Not sure I get what you're struggling with.

The yaml configuration file you're considering isn't related to docker, it's how your app reads the file.

As for environment variables, they don't have a 'type', they're just strings. Obviously you can write them as if they represent complex data types such as arrays, but it's not like they inherently contain that structure.