Could `TAILWIND_CLI_PATH` point to a binary?

[oliverandrich]

Discussed in https://github.com/oliverandrich/django-tailwind-cli/discussions/65

^{Originally posted by **jefftriplett** November 1, 2023} Wonderful tool btw. This is a one-part question and one-part help for anyone else who might be trying to wrap their head around making this work in Docker so that it doesn't try to re-download the tailwindcss binary every time `python manage.py tailwind ` is run. I'm using `django-tailwind-cli` in containers, and I found myself struggling/jumping through a few hoops to get the `tailwindcss` binary to work effectively. I mistakenly had `TAILWIND_CLI_PATH` set to `/usr/bin/tailwindcss` which created `/usr/bin/tailwindcss/tailwindcss-linux-x64-3.3.5`. What I'm using now is: ```Dockerfile ARG TAILWINDCSS_VERSION=3.3.5 ... # download the Tailwind CSS CLI binary ADD https://github.com/tailwindlabs/tailwindcss/releases/download/v${TAILWINDCSS_VERSION}/tailwindcss-linux-x64 \ /usr/bin/tailwindcss-linux-x64-${TAILWINDCSS_VERSION} RUN chmod 755 /usr/bin/tailwindcss-linux-x64-${TAILWINDCSS_VERSION} ... RUN DATABASE_URL=sqlite://:memory: python manage.py tailwind --skip-checks build ``` Would it make sense to allow users to set where the Tailwind CSS CLI binary is stored?

[oliverandrich]

@jefftriplett @oryon-dominik I like to have some comments from you before implementing.

The basic idea is obvious. If TAILWIND_CLI_PATH points to an existing directory, I try to find a suitable executable inside the directory. If non exists I will download it as the library has been doing from the beginning.

If TAILWIND_CLI_PATH points to an existing file, we skip the download process and just use the binary.

But what should the library if the path from TAILWIND_CLI_PATH does not exist in the filesystem? Currently, it assumes it is an directory and creates it in case it is missing. Then it downloads the CLI to this directory.

What would be your expectation if the TAILWIND_CLI_PATH is set to ~/Bin/tailwind-windows-x64-3.3.5.exe or to add an extra level of ambiguity ~/bin/tailwind-linux-arm64-3.3.5? Is this a path or not? Should I expect TAILWIND_CLI_PATH to end with an / if it is a path and otherwise treat it as a file?

Thanks for your input.

[oryon-dominik]

Personal taste:

• I would always use existing binaries (and the TAILWIND_CLI_PATH path directly pointing to the binary itself).
• Downloading only, if explicitly told so (TAILWIND_CLI_AUTO_DOWNLOAD = False). That means failing otherwise.
• Download to a directory TAILWIND_BASE_DIR not relying on BASE_DIR (example: I don't want to have BASE_DIR defined in my django settings - at least this should not crash).
• I'd also like tailwind.config.js to be part of that TAILWIND_BASE_DIR.

Regards

[jefftriplett]

I ended up with settings.TAILWINDCSS_VERSION = "3.3.5" and calling (without any of the other config):

RUN DATABASE_URL=sqlite://:memory: python manage.py tailwind --skip-checks build

I originally thought if TAILWIND_BASE_PATH were pointing at a binary it should use it. Upon further reading, it was more clear that you were using it for the folder where the binary should live.

I would probably do a check to see:

• if TAILWIND_BASE_PATH exists and is an executable then run it.
• If it does not exist, I would do your existing OS + arch check to see if that file exists (to save people like me some grief)
• If not, I would download and make assumptions

[oliverandrich]

I implemented the behaviour that TAILWIND_CLI_PATH can also point to an pre-installed binary. I also added the setting TAILWIND_CLI_AUTOMATIC_DOWNLOAD to enable (default) or disable the automatic download of the CLI if none is found locally.

[oryon-dominik]

This is working great on Windows. Thanks.