v1.0 prefixes "C:" to AUDIBLE_CONFIG_DIR

[philgoetz]

My audible-cli config directory is on drive E, because needs over 100G of space.
But I can't get the new release (from audible_win_dir.xip) to look for its config directory there, because it prepends 'C:' to the path, probably because it's a cygwin path and so doesn't look like a Windows path.
This was not a problem with the previous version.
(Although I don't know which release of audible-cli it's using, a precompiled one or one I compiled, because the config process was complicated, I don't know which Python installation cygwin is using, and I didn't keep good notes.)

$ printenv|grep AUDI
AUDIBLE_CONFIG_DIR=/cygdrive/e/data/audio_/Audible/audible-cli

# This calls the new binary executable file from audible_win_dir
$ audible library list
error: Config file C:\cygdrive\e\data\audio_\Audible\audible-cli\config.toml not found

# This calls the previous executable in /usr/local/bin, which was a script, not a binary
$ audible0 library list
[ correctly outputs a list of audiobooks ]

[mkb79]

The following function in config.py is selecting the config dir:

def get_app_dir() -> pathlib.Path:
    app_dir = os.getenv(CONFIG_DIR_ENV) or click.get_app_dir(
        "Audible", roaming=False, force_posix=True
    )
    return pathlib.Path(app_dir).resolve()

This function is untouched over one year.

Because using an env variable, in your case pathlib.Path("/cygdrive/e/data/audio_/Audible/audible-cli").resolve() is executed to get the config dir. The env var you use is a relative path. So it depends on the audible binary path, wich drive is used.

But why is you config dir so big? I'm using the default config dir and have the config.toml, the auth files and the plugins dir with plugin scripts only stored in it. I have multiple audible binarys with different versions in different places! And my audiobooks are stored on a NAS!

So I would suggest:

1. using the default config dir
2. put your binary in one location and verify, that this binary is in a path where Windows can find it (maybe add this dir to Windows paths)
3. switch to your audiobook dir and run your command or use the -o TARGET_DIR option of a command to specify the audiobook dir.

PS: You don't need cygwin or Python to run the standalone binarys!

Maybe this this helps you!

[philgoetz]

Because using an env variable, in your case pathlib.Path("/cygdrive/e/data/audio_/Audible/audible-cli").resolve() is executed to get the config dir. The env var you use is a relative path. So it depends on the audible binary path, wich drive is used.

No; it's an absolute path, because it starts with a '/'. Cygwin uses Unix conventions. The 'e' after 'cygdrive' means it's on drive E. (Cygwin treats 'e' and 'E' as equivalent for drive specification, though everywhere else, uppercase vs. lowercase matters.) The earlier version of audible-cli that I was using, used it as an absolute path. The binary might be the same; the version I was using before had a script rather than a binary in /usr/local/bin/audible; that script might have auto-converted the path.

I could try using a Windows-style env variable, but I suspect that would cause problems somewhere, because shell scripts wouldn't be able to interpret it correctly.

But why is you config dir so big?

audible-cli defaults to downloading in the current working directory, so I wanted that to be close to the config directory, so I could cd easily between the two. My Audible directory already contains a "downloads" directory, for files downloaded using the Audible app. So I put a "downloads" subdirectory inside "audible-cli", to put files downloaded by audible-cli. That downloads directory is huge.

[mkb79]

No; it's an absolute path, because it starts with a '/'. Cygwin uses Unix conventions. The 'e' after 'cygdrive' means it's on drive E. (Cygwin treats 'e' and 'E' as equivalent for drive specification, though everywhere else, uppercase vs. lowercase matters.)

Please keep in mind pyinstaller binarys use its own Python interpreter. Not the interpreter from Cygwin. So if you run the binary, the pathlib.Path.resolve function uses not the Cygwin path style!

[mkb79]

@philgoetz Could you solve your problem?

[mkb79]

#198 (comment)