nianeyna/ao3downloader
1
0
Fork 0
Code Issues 52 Pull requests Projects Releases Packages Wiki Activity Actions

Extension for download sub-folder, add series-id to file-pattern. #194

Closed
alexmaul wants to merge 2 commits from distinct_series into main
pull from: distinct_series
merge into: nianeyna:main
Conversation 3 Commits 2 Files changed 5 +31 -10
alexmaul commented 2025-01-28 01:23:13 -05:00 (Migrated from github.com)
Copy link

Refers to issue #183, maybe #139

  • Makes series number available in FileNamePattern and the new DirNamePattern.
  • Several (hopefully small enough) changes to allow sub-folders in the default download folder.
    The changes in settings.ini suggest sub-folders by series number/titel, but any of the other file name pattern are good for it, too.
Refers to issue #183, maybe #139 - Makes series number available in FileNamePattern and the new DirNamePattern. - Several (hopefully small enough) changes to allow sub-folders in the default download folder. The changes in `settings.ini` suggest sub-folders by series number/titel, but any of the other file name pattern are good for it, too.
nianeyna commented 2025-01-28 15:41:41 -05:00 (Migrated from github.com)
Copy link

I think this is going in the right direction, but I don't like having the separate ini variable for the subdirectory. It feels a little messy, plus, it only allows one level of nesting. Say someone wanted to organize by fandom first, then series - this doesn't allow that.

Instead, I propose allowing the special character / inside FileNamePattern to represent directories. This allows users to construct any directory structure they prefer, while (hopefully) keeping the code changes fairly simple - you can probably keep most everything the same except for some changes in fileio.save_bytes.

Make sure to consider the following in your implementation:

  • What happens if a section of the pattern evaluates to an empty string

    • For example, say the pattern is {fandom}/{series_title}/{title}. For works that are not in a series, a naive implementation will result in a folder path that looks like Fandom//Title.epub which is not valid. You will need to come up with some way of handling this that will be intuitive for the user.

  • File name truncation must not result in nonsensical file paths

    • For example, if the file path is {fandom}/{title}, and the fandom name is longer than FileNameLength, if you truncate the pattern as a whole, every fic in that fandom will be saved in the root directory as "{partial fandom name}.epub". (Even worse, they'll all overwrite each other because they will have the exact same file name.) Make sure to handle this type of scenario in some way.

  • Optionally, you might want to include a way to choose how fics with multiple values in one of the variables are organized

    • For example, if your pattern is {fandom}/{title} and you download a crossover, you'll end up with a folder structure like
    /Fandom 1
  /work1.epub
/Fandom 1, Fandom 2
  /work2.epub
/Fandom 2 
  /work3.epub

    I think that's basically fine, and has the advantage that each work is only saved once, but it might be cool to include some way to indicate (maybe using another one of the reserved special characters) that a variable in the folder path should be split out like so

    /Fandom 1
  /work1.epub
  /work2.epub
/Fandom 2
  /work2.epub
  /work3.epub

    Like I said, totally up to you if you want to attempt this one, but it could be a fun challenge!

Thanks again for your work on this, and if you run into any problems (or anything is unclear) please feel free to ping me with questions any time.

I think this is going in the right direction, but I don't like having the separate ini variable for the subdirectory. It feels a little messy, plus, it only allows one level of nesting. Say someone wanted to organize by fandom first, then series - this doesn't allow that. Instead, I propose allowing the special character `/` inside FileNamePattern to represent directories. This allows users to construct any directory structure they prefer, while (hopefully) keeping the code changes fairly simple - you can probably keep most everything the same except for some changes in fileio.save_bytes. Make sure to consider the following in your implementation: - What happens if a section of the pattern evaluates to an empty string - For example, say the pattern is `{fandom}/{series_title}/{title}`. For works that are not *in* a series, a naive implementation will result in a folder path that looks like `Fandom//Title.epub` which is not valid. You will need to come up with some way of handling this that will be intuitive for the user. - File name truncation must not result in nonsensical file paths - For example, if the file path is `{fandom}/{title}`, and the fandom name is longer than FileNameLength, if you truncate the pattern as a whole, every fic in that fandom will be saved in the root directory as "{partial fandom name}.epub". (Even worse, they'll all overwrite each other because they will have the exact same file name.) Make sure to handle this type of scenario in some way. - *Optionally*, you might want to include a way to choose how fics with multiple values in one of the variables are organized - For example, if your pattern is `{fandom}/{title}` and you download a crossover, you'll end up with a folder structure like ``` /Fandom 1 /work1.epub /Fandom 1, Fandom 2 /work2.epub /Fandom 2 /work3.epub ``` I think that's basically fine, and has the advantage that each work is only saved once, but it might be cool to include some way to indicate (maybe using another one of the reserved special characters) that a variable in the folder path should be split out like so ``` /Fandom 1 /work1.epub /work2.epub /Fandom 2 /work2.epub /work3.epub ``` Like I said, totally up to you if you want to attempt this one, but it could be a fun challenge! Thanks again for your work on this, and if you run into any problems (or anything is unclear) please feel free to ping me with questions any time.
alexmaul commented 2025-01-30 00:59:37 -05:00 (Migrated from github.com)
Copy link

Thank you for your points!

A // in the path shouldn't be a problem on Linux systems, but I'm not sure about Windows -- it's better to remove it.

The file name truncation was the main reason I introduced the new DirNamePattern -- I'm with you removing that and allowing / in FileNamePattern is a better way.

How to handle works belonging to multiple fandoms/series might be a tricky one ... I'd prefer the second of your options. Not sure how other people'd see that?

I'll update my PR next week.

Thank you for your points! A `//` in the path shouldn't be a problem on Linux systems, but I'm not sure about Windows -- it's better to remove it. The file name truncation was the main reason I introduced the new DirNamePattern -- I'm with you removing that and allowing `/` in FileNamePattern is a better way. How to handle works belonging to multiple fandoms/series might be a tricky one ... I'd prefer the second of your options. Not sure how other people'd see that? I'll update my PR next week.
nianeyna commented 2025-11-20 20:13:24 -05:00 (Migrated from github.com)
Copy link

Functionality has now been rolled into the program - thank you again for your work on this!

Functionality has now been rolled into the program - thank you again for your work on this!

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
nianeyna/ao3downloader!194
No description provided.