You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current way to use a externally compiled/provided libvips depends on automatically detection of the sharp installer scripts. This has some flaws and can produce very inconsistent experience as it is not always clear if the external library is being used or the provided pre-compiled libs.
One of my services requires for example PDF support with libvips and i have to compile it at my own, but there is absolutely no way to enforce usage.
So it happens when there is a mismatch on the minimum required vips version, it silently installs the pre-compiled version and ignores the globally provided libvips, what can result into a broken service as certain formats are suddenly not supported.
When you searched for similar feature requests, what did you find that might be related?
What would you expect the API to look like?
I would be fine with a environment variable to control this behavior.
Opposite to SHARP_IGNORE_GLOBAL_LIBVIPS something like SHARP_FORCE_GLOBAL_LIBVIPS
What alternatives have you considered?
I have currently a short assertion test after installing the libraries to ensure all dependencies are correctly setup, but its more a safeguard than a solutions:
test "true" = "$(node -e "console.log(require('sharp').format.pdf.input.stream)")"
Please provide sample image(s) that help explain this feature
The text was updated successfully, but these errors were encountered:
Thanks for the suggestion, this is a good idea for more advanced users that are comfortable building their own custom libvips. I've added it via commit 579cf93
An alternative fail-fast technique might be to pass the --build-from-source flag and then remove the node_modules/@img directory (or somehow block it in the first place).
I had to kill my terminal sessions, installed and removed both sharp locally and as root, then, installed it locally again using the following:
npm install sharp --build-from-source --verbose --foreground-scripts Restarting my Terminal session and then running the above again resolved the issue. Let me know if you need any other info, or if anyone else needs assistance.
Original Below:
I think this issue is the cause of #2518.
and #4050
Unfortunately it did not resolve the issue of unsupported codec for heif. I can manually do it through vips copy image.heic image.jpeg.
(I note you are compiling libvips from source control rather than using a published version. Please remember this is not yet released and therefore has not yet been fully tested with sharp so you may have run into a separate problem.)
Feature request
What are you trying to achieve?
The current way to use a externally compiled/provided libvips depends on automatically detection of the sharp installer scripts. This has some flaws and can produce very inconsistent experience as it is not always clear if the external library is being used or the provided pre-compiled libs.
One of my services requires for example PDF support with libvips and i have to compile it at my own, but there is absolutely no way to enforce usage.
So it happens when there is a mismatch on the minimum required vips version, it silently installs the pre-compiled version and ignores the globally provided libvips, what can result into a broken service as certain formats are suddenly not supported.
When you searched for similar feature requests, what did you find that might be related?
What would you expect the API to look like?
I would be fine with a environment variable to control this behavior.
Opposite to
SHARP_IGNORE_GLOBAL_LIBVIPS
something likeSHARP_FORCE_GLOBAL_LIBVIPS
What alternatives have you considered?
I have currently a short assertion test after installing the libraries to ensure all dependencies are correctly setup, but its more a safeguard than a solutions:
test "true" = "$(node -e "console.log(require('sharp').format.pdf.input.stream)")"
Please provide sample image(s) that help explain this feature
The text was updated successfully, but these errors were encountered: