python27 2.7.3_0 py27-gtk 2.22.0_1 etc -- pkg-config files not installed correctly for python 2.6 and 2.7 versions of pygtk and pygobject

[snarkhunter (Steve Langer)]

I don't know which port this bug belongs to, so I've included all of the possibilities. I hope that's not bad etiquette.

The ports py26-gtk, py27-gtk, py26-gobject, and py27-gobject do not install their .pc files (pygtk-2.0.pc and pygobject-2.0.pc) in /opt/local/lib/pkgconfig. Instead, they leave the files in /opt/local/Library/Frameworks/Python.framework/Versions/2.*/lib/pkgconfig/. Shouldn't "port select --set python python2.7" copy the appropriate files to /opt/local/lib/pkgconfig?

The problem may be that py25-gtk and py25-gobject install their .pc files directly into /opt/local/lib/pkgconfig, which means that port select can't install the py26 or py27 files without trashing the py25 files.

Background: I develop and distribute software that uses pkg-config in its installation script, and works with python 2.5, 2.6, or 2.7. I therefore have py25-gtk, py26-gtk, and py27-gtk all installed. When I build the software locally it uses the python 2.5 version of pygtk-2.0.pc and pygobject-2.0.pc no matter which python version I'm currently using. This doesn't actually seem to cause a problem. However, the build fails for users who have never installed py25-gtk and py25-gobject, unless they explicitly set PKG_CONFIG_PATH. I don't think this should be necessary.

[snarkhunter (Steve Langer)]

Cc Me!

[michaelld (Michael Dickens)]

Cc Me!

[michaelld (Michael Dickens)]

I just came upon this issue as well, and it certainly is an issue. I think the "select" files for "python" should be able to link the -python- .pc files into ${prefix}/lib/pkgconfig from the Python Framework's pkgconfig directory. For the others there needs to be a naming scheme such that multiple versions can be installed into ${prefix}/lib/pkgconfig at the same time -- e.g., gtk+-2.0-python25.pc, gkt+-2.0-python26.pc and so forth (or, something like this). Ugly, but at least there would not be conflicts in the installed .pc files' names. Each actual .pc file would probably be best installed into the Python Framework's pkgconfig directory, but there's no good way to dynamically "select" every single Python package that I know of & hence the linking into ${prefix}/lib/pkgconfig would require some odd naming convention.

[snarkhunter (Steve Langer)]

I think changing the name of the .pc files is a bad idea. One of the main reasons for using pkgconfig is that it helps to make programs portable to different systems, so the file name has to be standard.

[michaelld (Michael Dickens)]

I am really hoping that a MP dev who knows how "select" works internally can comment on this issue.

[michaelld (Michael Dickens)]

I'd love to have one select a version of Python and then have all of the .pc files in its pkgconfig directory selected as well, both those already installed and those to be installed. But, I don't think select works that way. I think, in order for the .pc filenames to be correct, we can: (1) installed them into the correct Framework directories, with the correct filenames, but have them not be accessible in ${prefix}/lib/pkgconfig; (2) make the ports conflict with one another, such that only once version can be installed for any given Python at a time; or (3) mess with the .pc file names and have all available at the same time. None are great solutions, IMHO. But, I cannot think of another way to do this if select works as I think it does.

[snarkhunter (Steve Langer)]

Maybe hack pkg-config so that it always checks the current python version and automagically adds /opt/local/Library/Frameworks/Python.framework/Versions/2.*/lib/pkgconfig/ to its search path? Or make it check a standard directory for files that list the directories that it should add to the path. Then each python package could contain one of those files, and port select would install the correct one.

[michaelld (Michael Dickens)]

I like the idea of having the PKG_CONFIG_PATH variable point to the top-level directories inside of which pkg-config should search for .pc files. We could then create a link from the Python Framework's pkgconfig directory into ${prefix}/lib/pkgconfig/pythonXY, and have pkg-config search not just the primary directory but also any subdirectories (direct or via links). While I like this idea, it changes the behavior of pkg-config to be non-standard beyond what is reasonably expected; thus, I don't see it happening. That said, I think talking with the pkg-config developers about the feature would be a good way to go. It really does sound like a good feature to me. Maybe it already exists and I/we just don't know it? Have to check this out.

[michaelld (Michael Dickens)]

At least in my testing, pkg-config does not do a recursive search yet; it looks just in the directories provided, not subdirectories.

[ryandesign (Ryan Carsten Schmidt)]

Hello, pkgconfig maintainer here.

The reason the Python 2.5 (and earlier) versions in MacPorts install directly into /opt/local/lib/pkgconfig is because they are not framework builds. Python 2.6 and later are framework builds in MacPorts, and therefore install their files into the deep directory you mentioned earlier. Understanding how or why Python 2.5 and earlier do what they do is not very useful since Python 2.4 is already being deleted and 2.5 is hopefully not far behind. The way Python 2.6 and later are built is the way we want Python built in MacPorts going forward.

I think the correct solution is what you already mentioned in the description you don't want to do: set PKG_CONFIG_PATH properly. If you want to find Python 2.6 bits, set PKG_CONFIG_PATH to include Python 2.6's pkgconfig directory, etc. It's up to each port to do this, because it's up to each port to know which version(s) of Python it wants. We might conceivably reduce the burden on port maintainers by making a portgroup to automate that but we don't have one to do that right now.

[snarkhunter (Steve Langer)]

Replying to ryandesign@…:

Hi Ryan --

Thanks for the comments. I'll modify my setup scripts so that they detect if macports is being used, and set PKG_CONFIG_PATH accordingly. However, it seems wrong to have to hard code such a deep path.

This seems to be a deficiency in pkg-config that must affect other package management systems, not just macports. It could be fixed by giving pkg-config a path extension method, such as python's .pth files. Then python27 could install /opt/local/lib/pkgconfig/python.pth, which would contain the string "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pkgconfig/". Since python.pth would be part of each python package, the correct version would be installed by "port select".

Does that sound feasible? Is it worth contacting the pkg-config developers?

-- Steve

[ryandesign (Ryan Carsten Schmidt)]

It seems that we should at least modify the python portgroup to set PKG_CONFIG_PATH so that, say, py27-keybinder would not have this problem finding py27-gobject.

[cooljeanius (Eric Gallager)]

Cc Me!

[cooljeanius (Eric Gallager)]

I tried to get around this by changing my PKG_CONFIG_PATH by editing my ~/.profile file, but Macports is still failing to pick them up. Should I be changing my PKG_CONFIG_PATH in a different way?

[ryandesign (Ryan Carsten Schmidt)]

MacPorts deliberately does not make use of any environment variables you have set in ~/.profile or elsewhere in your shell environment; MacPorts uses its own internal sanitized set of environment variables. In this ticket we are discussing changes that we would need to make to portfiles and portgroups to set PKG_CONFIG_PATH correctly in that internal sanitized set of variables.

[nonstop.server@…]

Cc Me!

[mparchet@…]

Cc Me!

[khepler]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

proposed patch

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

It seems that we should at least modify the python portgroup to set PKG_CONFIG_PATH so that, say, py27-keybinder would not have this problem finding py27-gobject.

I've added the patch I've been using for this for some time. I will commit it soon, and fix the ports that manually set PKG_CONFIG_PATH, since that conflicts with this (e.g. #43261).

[petrrr]

Cc Me!