chrismytton / heroku-buildpack-jq

If this buildpack is run on a Heroku stack / base image where JQ already exists as a system installed package, this buildpack has a bug that prevents JQ from running:

$ mkdir jq-test && cd $_
$ git init && touch foo && git add -A && git commit -m '.'
$ heroku create --buildpack https://github.com/chrismytton/heroku-buildpack-jq
$ git push heroku main
...
remote: -----> Building on the Heroku-22 stack
remote: -----> Using buildpack: https://github.com/chrismytton/heroku-buildpack-jq
remote: -----> jq app detected
remote: -----> Discovering process types
remote:        Procfile declares types -> (none)
remote:
remote: -----> Compressing...
remote:        Done: 1.1M
...
$ heroku run jq --version
Running jq --version on ⬢ blooming-bayou-87976... up, run.4689 (Basic)
jq: symbol lookup error: jq: undefined symbol: jv_object_has

This is because the buildpack adds its own JQ last to PATH, rather than at the front of PATH:

heroku-buildpack-jq/bin/compile

Lines 11 to 16 in 61f90ba

    
           function set-default-env (){ 
        
             echo "export $1=\$$1:/app/vendor/jq/$2" >> $PROFILE_PATH 
        
           } 
        
           set-default-env LD_LIBRARY_PATH "lib" 
        
           set-default-env PATH "bin"

This then means that when jq is run, the system jq is run instead of the buildpack jq.

This would in itself be fine, however, the LD_LIBRARY_PATH set by the buildpack (so that the buildpack jq can find its vendored library) takes precedence over any system libraries. This means system jq tries to run against the jq library vendored by this buildpack, which breaks when the jq version in the base image is newer than the library vendored by this buildpack (so is missing interfaces added in newer versions).

This is particularly relevant now that jq has been added to Heroku's run images, in:
https://devcenter.heroku.com/changelog-items/2893

To fix the buildpack needs to either:

Add its own jq to the front of PATH (not the back)
Or, skip installing jq entirely if jq exists in the base image already. However, jq being in the build time image doesn't necessarily mean it's available at run time, and there's really no way for the buildpack to know programatically. Perhaps a warning message is the best that can be done?

Thanks for this!

I'm not actively using the buildback myself, but I would be happy to accept a pull request addressing this issue.

@chrismytton Hi! Great thank you - sorry I should have said above I was about to open a PR so don't spend any time on it :-)

I've opened #4 to fix this :-)

	function set-default-env (){
	echo "export $1=\$$1:/app/vendor/jq/$2" >> $PROFILE_PATH
	}

	set-default-env LD_LIBRARY_PATH "lib"
	set-default-env PATH "bin"

Buildpack breaks system installed JQ installation if it exists