plugin version not resolved with ruby pg gem

[mlwilkerson]

Steps to reproduce

1. set up .tool-versions with:

postgres 9.4.7
ruby 2.6.2

2. asdf install (successful)

3. gem install bundler (successful)

4. gem install pg

Expected behavior

The pg gem should be able to build its native extensions as part of installation.

Its build process relies on pg_config, which is shimmed via the postgres plugin.

Actual behavior

$ gem install pg
Building native extensions. This could take a while...
ERROR:  Error installing pg:
    ERROR: Failed to build gem native extension.

    current directory: /Users/mike/.asdf/installs/ruby/2.6.2/lib/ruby/gems/2.6.0/gems/pg-1.1.4/ext
/Users/mike/.asdf/installs/ruby/2.6.2/bin/ruby -I /Users/mike/.asdf/installs/ruby/2.6.2/lib/ruby/2.6.0 -r ./siteconf20190329-82337-1d85knm.rb extconf.rb
checking for pg_config... yes
Using config values from /Users/mike/.asdf/shims/pg_config
asdf: No version set for command pg_config
you might want to add one of the following in your .tool-versions file:

postgres 9.4.7
asdf: No version set for command pg_config
you might want to add one of the following in your .tool-versions file:

Environment

OS: macOS 10.14.3

asdf version: master @ 5d40982

Comments

When executing pg_config directly from the command line, through the asdf shim, it resolves to the correct pg_config binary and runs successfully. The problem occurs when the pg_config shim is invoked in the context of gem install.

After adding some debug output to lib/utils.sh, I can see that search_path is populated from pwd, which in this case is: /Users/mike/.asdf/installs/ruby/2.6.2/lib/ruby/gems/2.6.0/gems/pg-1.1.4/ext. As a result, usable_plugin_versions remains empty.

It seems that asdf assumes that pwd is going to return the directory in which my .tool-versions lives, which does have postgres 9.4.7 in it.

For now, the way I'm working around this is to set a bundler config to circumvent the use of the pg_config shim and use the installed pg_config binary directly.

Possibly related: #488

[AlexeyMatskevich]

I experienced the same problem in the Arch linux distribution. Installing postgresql-libs helped me. Maybe you need to install a similar package for your system.

[mpugach]

setting asdf global postgres 9.4.7 helped me

[Hacklor]

Thank you for reporting!

I ran into the same issue when trying to run a Rails project with postgres and ruby installed via asdf. I didn't have the time to look into it further so I switched back to HomeBrew for postgres.

Is this a problem with asdf itself, or with the plugin maker of postgres?

I would love to see it working in the future!

[pvinis]

I also needed to do brew install postgres. I guess pg needs postgres on the system already, either from asdf or just brew or any other way.

[serodriguez68]

@mlwilkerson did you find a solution for this without defaulting back to homebrew or setting asdf global postgres x.y.z?

[mlwilkerson]

@serodriguez68 it's been a while, so my memory is fuzzy, but I think I just worked around this issue somehow and never actually solved it.

[fdr]

I have confirmed this on Fedora 32 as well. asdf global does the trick. But....seems bad. I was also perplexed since pg_config was executing all right and had the correct paths being listed.

$ asdf version
v0.7.8-4a3e3d6

[jthegedus]

So, correct me if I am understanding this wrong, we would need to modify the search_path command's search for .tool-versions when shims are executed from another tool.

Anyone have suggestions for how this could be solved? Is passing pwd to any shim feasible?

[nathanjo]

This is still an issue. Setting it to global though works but I think not really the solution we're looking for. For now manually installing the gem pg using the --with-pg-config will do.

[dtbaker]

Same as @mpugach - doing asdf global postgres 11.5 sorted it for me

[ashmckenzie]

In the context of postgres installed via asdf but no global version set, gem and bundle need a helping hand. It's important to use the full postgres install path, not the 'shim' path because that won't work:

gem

$ gem install pg -- --with-pg-config=${ASDF_DIR}/installs/postgres/<version>/bin/pg_config

bundle

$ bundle config build.pg --with-pg-config=${ASDF_DIR}/installs/postgres/<version>/bin/pg_config

or if you don't want to use an environment variable:

$ export BUNDLE_BUILD__PG="--with-pg-config=${ASDF_DIR}/installs/postgres/<version>/bin/pg_config"

[Stratus3D]

@ashmckenzie the asdf where command can be helpful in commands like those:

gem

gem install pg -- --with-pg-config=$(asdf where postgres)/bin/pg_config

bundle

bundle config build.pg --with-pg-config=$(asdf where postgres)/bin/pg_config

environment variable

export BUNDLE_BUILD__PG="--with-pg-config=$(asdf where postgres)/bin/pg_config"

As long as you run these commands in a directory where you have the correct postgres version set everything will work.

[Stratus3D]

So, correct me if I am understanding this wrong, we would need to modify the search_path command's search for .tool-versions when shims are executed from another tool.

Anyone have suggestions for how this could be solved? Is passing pwd to any shim feasible?

I don't have any ideas. I don't think passing pwd to any shim is viable because other (non-asdf) commands would have to pass it along. If I understand this problem correctly Ruby's gem command would have to actually pass pwd to the pg_config shim:

• user shell process is in correct directory, invokes gem install
• gem install does some magic to install the gem, eventually tries to invoke pg_config in another directory that doesn't have a .tool-versions` file and the command fails with the version error message.

[oamado]

Also worked for me gem install pg -v '0.18.4' -- --with-cflags="-Wno-error=implicit-function-declaration"

[jthegedus]

@Stratus3D Is this something we can actually resolve by changing code in this repository, is it a problem with asdf core, or can we call this something we need to add to the FAQ to close out this Issue?

[Stratus3D]

@jthegedus this is a tough one. For this specific issue there is nothing we can resolve by changing asdf core code. Since this is specific to the Ruby pg gem I don't know that even the asdf-ruby plugin should be handling this (otherwise for consistency it'd need to handle configuration issues for all gems and it'd also have to know about the presence of the asdf-postgres gem).

Documenting the solution to this would be good but it poses additional challenges. For example, this specific issue is when someone is using both the ruby and postgres plugins together for the same project. I'm not sure which repo we'd still the documentation in (asdf-ruby vs asdf-postgres). And there are many other similar scenarios that solution I posted would not work for. For example, someone using the ruby and postgres plugins but wanting to use the OS-installed postgres instance.

[jthegedus]

We could have a "kitchen sink" page in the docs under a recipes section that captures these edge cases where we document and update the caveats. It might help direct people searching the web to a solution than to opening new Issues or piling on old threads. Thoughts?

[Stratus3D]

That sounds great @jthegedus !

[aalvarado]

Only adding the pg_config flag didn't work for me. I had to do this instead:

gem install pg -- --with-pg-config=$(asdf where postgres)/bin/pg_config --with-pg-include=$(asdf where postgres)/include --with-pg-lib=$(asdf where postgres)/lib