Add file as a system requirement in the docs
olingern opened this issue · comments
Brief Description
I was debugging file uploads in our production docker build and received this error:
file command-line tool is not installed
which originates here:
Expected behavior
- Docs explain what system tools are required to be installed
- It would be nice if Shrine could validate upon load whether or not file is present and warn or throw an error if not.
Actual behavior
No output and crash upon upload when file does not exist on the sytem
Simplest self-contained example code to demonstrate issue
n/a
System configuration
Ruby version:
2.6
Shrine version:
2.14.0
Thank you for the issue. We did try to mention in the doc's that system file utility is available in most OS's except windows where it needs to be installed - we thought that would be a good enough hint for dev's to double check (see doc). We haven't tested it on every combination of platform's available and I think you're the first who's mentioned it's not available in your docker build.
I agree it would be nice to check on load and we'll take your suggestion into consideration. If you have an idea of how you'd like it to behave, we would welcome a PR.
The file command is not technically a requirement for Shrine. It is used as the default analyzer when the determine_mime_type plugin is loaded (and that is stated in the README), but if you choose a different analyzer (e.g. :marcel), the file command is not used. That's even one of the reasons to choose a different analyzer – if the file command is not available in your system.
In addition to that, we've received reports of some non-deterministic errors with the file command, so we're considering changing the default MIME type analyzer to the Marcel gem in Shrine 3.0 (which is the same analyzer Active Storage uses). In this case I would seriously consider just adding Marcel as a dependency to Shrine, and analyzing the MIME type with it by default, instead of the current default behaviour which is to just read the #content_type attribute of the input IO object if it exists.
This change is something we can only do in Shrine 3.0, as Marcel will likely analyze MIME types differently than the file command, so it would be a breaking change.
@hmistry One idea I have is once the mime type selector is set, to check and see if exists on the system. I would see this living here. Since configuration occurs in initialization -- this could catch a missing system dependency. What do you think?
The file command is not technically a requirement for Shrine. It is used as the default analyzer when the determine_mime_type plugin is loaded (and that is stated in the README)
@janko I glossed over this and could chalk this mostly up to user error. I think Shrine being as decoupled (which is great ) as it is puts an onus on the user to correctly identify their dependencies. So, switching to Marcel (or mimemagic since Marcel calls itself a "thin wrapper" around mimemagic ) could simplify that a bit.
One idea I have is once the mime type selector is set, to check and see if exists on the system. I would see this living here. Since configuration occurs in initialization -- this could catch a missing system dependency. What do you think?
I think that will work. Since checking for the file command will make a shell call, you probably want to verify that it's not called multiple times just in case. There are some sample test scripts which helps simplify testing.
Is getting an exception while loading the plugin significantly better than getting it on runtime when attaching a file? I feel like it's almost the same, as you get notified either way.
Considering that we'll be changing the default analyzer, and possibly even adding it to base functionality, I don't feel like it's worthwhile to add that additional check for the file analyzer (and adding a performance penalty of executing a shell command at load time).
Yes, for me it's better UX because if I choose the file analyzer, whether by default or choice, I kind of expect an app to not load if I'm missing a prerequisite. It should behave the same way like when you're missing a gem or require statement.
I agree with janko that how it is now is sufficient. Configs like that can be changed at runtime, I think, yes? I think it would be hard to correctly fail at the right time without over- or under-failing, except by fail on use.
The :file analyzer will stay the default even in Shrine 3.0, mainly because it's very convenient that it doesn't require any gems that the user needs to remember to add. However, the documentation now recommends using the :marcel MIME type analyzer, because it's a safer option for deployment.
To address the expected behaviour in the issue description:
- Docs explain what system tools are required to be installed
The :file analyzer description does indicate that the file command needs to be installed:
Uses the file utility to determine the MIME type from file contents. It is installed by default on most operating systems, but the Windows equivalent needs to be installed separately.
- It would be nice if Shrine could validate upon load whether or not file is present and warn or throw an error if not.
I don't want Shrine to execute any shell commands on load. I've had very bad experience doing that in the MiniMagick gem, I don't think it's entirely safe.
Since :marcel is now the recommended MIME type analyzer, I think people will encounter this issue far less often.