Add link to community plugin
[`beets-filetote`](https://github.com/gtronset/beets-filetote).
This plugin is the spiritual successor to
[beets-copyartifacts](https://github.com/adammillerio/beets-copyartifacts)
(`beets-copyartifacts3` was last updated 3 years ago) and
[beets-extrafiles](https://github.com/Holzhaus/beets-extrafiles) (last
updated 5 years ago).
Given the updates and changes in beets and how outdated those plugins
are, does it make sense to keep `beets-copyartifacts` in the community
plugins list?
---------
Co-authored-by: Sebastian Mohr <39738318+semohr@users.noreply.github.com>
A rebased & amended version of
https://github.com/beetbox/beets/pull/4649.
I left a FIXME note regarding a cleanup that I feel should be done at
some point, but that is out-of-scope here when just adding initial
typings.
Notably, this replaces the `Shareable` metaclass by a different implementation
of a descriptor: We don't really need to modify class creation here,
because the singleton is only available via the `shared` method, not via
the constructor. Additionally, it appears that mypy can understand the
new code.
This is more of a "what should the types be", in particular regarding
paths, it has not yet been run through mypy. That will be done next,
which is probably going to highlight a bunch of issues that should lead
to either the code being fixed, or the types adjusted.
This PR addresses an issue where path legalization, specifically the
`truncate_path` function, incorrectly removed parts of filenames that
followed a dot. This occurred because `pathlib.Path.with_suffix` was
used, which replaces the existing suffix (or what it considers a suffix)
rather than just appending.
The fix modifies `truncate_path` to manually append the original suffix
after truncating the filename stem. This ensures that dots within the
filename, not part of the actual extension, are preserved.
Fixes#5771.
Also tighten `filetype` attribute type - empty value was previously
handled to accommodate a couple of tests, but they aren't failing
anymore, it seems.
TIL that `with_suffix` does not simply append the suffix to the filename
- it instead replaces the old/current suffix. Or whatever seems to
look like a suffix, in our case, unfortunately...
This PR addresses Dependabot vulnerability alerts and secret scanner
reports by updating dependencies and redacting some of the sensitive
configuration field.
* **Dependency Updates:** Updated various dependencies, including those
flagged by Dependabot, as reflected in `poetry.lock`. This resolves
known vulnerabilities.
* **Secret Redaction:** Addressed secret scanner findings by redacting
sensitive configuration values (e.g., `tokenfile`, `apikey`, `password`,
`username`, `userid`) in `beatport`, `discogs`, `embyupdate`,
`fetchart`, `lastimport`, `spotify`, and `subsonicupdate` plugins.
* **Python Version:** Standardized on Python 3.9 across GitHub Actions
workflows.
* **Code Style:** Minor adjustments for `ruff` compatibility, including
string concatenations and f-string quote consistency.
These have probably not been run by anyone in ages, better to move the
code to our test suite where it is regularly exercised. In fact, the
latter covers most of the cases already. The only missing tests seem to
be those were exceptions are raised in the first or last stage. Thus,
this adds such tests.
These have probably not been run by anyone in ages, better to move the
code to our test suite where it is regularly exercised. In fact, the
latter covers most of the cases already. The only missing tests seem to
be those were exceptions are raised in the first or last stage. Thus,
this adds such tests.
**Refactor: Simplify Path Generation and Legalization**
This PR refactors the way destination paths for library items are
generated and made filesystem-safe. The goal is to simplify the process,
make it more robust, and centralize most of the path manipulation logic.
**Key Changes:**
* **`Item.destination` Simplified:**
* The method now has a clearer interface, primarily controlled by the
`relative_to_libdir` flag (replacing the old `fragment` flag).
* It consistently returns the path as `bytes`, ready for filesystem
operations.
* Path legalization logic (sanitization, truncation, replacements) is
now delegated to `util.legalize_path`.
* **`util.legalize_path` Enhanced:**
* Takes responsibility for the full legalization process, including
truncation based on filesystem limits.
* Uses new helper functions (`util.truncate_path`, `util.truncate_str`)
for robust truncation of path components while preserving extensions and
handling multi-byte characters correctly.
* Includes logic to handle potential conflicts where
sanitization/replacements might interfere with truncation, falling back
to default rules if necessary.
* **Centralized Max Length:**
* A new cached function `util.get_max_filename_length` determines the
maximum filename length, checking the config first and then querying the
filesystem.
This refactoring leads to cleaner code by separating concerns:
`Item.destination` focuses on generating the *intended* path based on
metadata and formats, while `util.legalize_path` and its helpers handle
the complexities of making that path valid for the target filesystem.
