py27-yaml links with libyaml even if the libyaml variant is not selected

[ryandesign (Ryan Carsten Schmidt)]

py27-yaml links with libyaml even if the libyaml variant is not selected:

$ port -v installed py27-yaml
The following ports are currently installed:
  py27-yaml @3.10_1 (active) platform='darwin 12' archs='noarch'
$ port contents py27-yaml | grep so$
  /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_yaml.so
$ otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_yaml.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_yaml.so:
	/opt/local/lib/libyaml-0.2.dylib (compatibility version 3.0.0, current version 3.2.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

Is there a reason why a user wouldn't want to use libyaml? Why not just always use it, and remove the variant?

Also, you'll see the port claims to be noarch, but is clearly not:

$ lipo -info /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_yaml.so
Architectures in the fat file: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_yaml.so are: x86_64 i386 

[deric@…]

I've investigated this by installing py27-yaml with libyaml not installed, and then installing libyaml specifically before I installed py27-yaml to see if there was some kind of opportunistic linking going on. But I can only get it to link against libyaml if I add the +libyaml variant.

As for if the variant should even exist, I'm not sure. It's an optional dependency and as such I usually like to have them turned off unless requested.

In any case, when the libyaml dependency is included it should have the right supported_archs flag, would updating the Portfile with "i386 ppc ppc64 x86_64" for supported_archs when linking against libyaml be ok? I'm currently limited to a rMBP to actually test it on.

[ryandesign (Ryan Carsten Schmidt)]

Replying to deric@…:

I've investigated this by installing py27-yaml with libyaml not installed, and then installing libyaml specifically before I installed py27-yaml to see if there was some kind of opportunistic linking going on. But I can only get it to link against libyaml if I add the +libyaml variant.

I've attached my log; perhaps you can compare it with yours.

As for if the variant should even exist, I'm not sure. It's an optional dependency and as such I usually like to have them turned off unless requested.

Assuming the library provides the python module with some benefit, then it should probably be always on, otherwise ports that depend on the python module can't really rely on the library's presence.

In any case, when the libyaml dependency is included it should have the right supported_archs flag, would updating the Portfile with "i386 ppc ppc64 x86_64" for supported_archs when linking against libyaml be ok? I'm currently limited to a rMBP to actually test it on.

That, or just put supported_archs noarch when the variant is not selected.

[deric@…]

Thanks for the log, I retested on a 10.7 box and it is actually opportunistically linking if libyaml is already installed. What you suggested makes sense to fix this: remove the variant and always link against libyaml. Is it possible to then also deprecate the 24 version of the port? Just remove "24" from python.versions?

[ryandesign (Ryan Carsten Schmidt)]

py24-nltk and py24-smisk depend on py24-yaml so if it's not too inconvenient I'd keep it around.

But yes, if you were going to remove a Python version from a module, you would just remove it from the python.versions line.

[deric@…]

Alright I've but some more work into fixing this. PyYAML 3.09 which is the latest version supported on Python 2.4 can actually link against LibYAML as well so there's no reason to treat it differently. So the actual change boils down to removing 'noarch' , always adding libyaml as a library dependency and removing the variant. Portfile is attached, should I revbump this?

[ryandesign (Ryan Carsten Schmidt)]

Replying to deric@…:

Alright I've but some more work into fixing this. PyYAML 3.09 which is the latest version supported on Python 2.4 can actually link against LibYAML as well so there's no reason to treat it differently. So the actual change boils down to removing 'noarch' , always adding libyaml as a library dependency and removing the variant. Portfile is attached,

Looks good to me!

should I revbump this?

Yes, since it changes how the port installs, for users who did not already have libyaml installed. You should change the "revision 1" line to "revision 2" under the version line at the top of the portfile, and add a "revision 1" line under the version line in the python 2.4 section of the portfile.

[deric@…]

Commited in r106537, thanks for your help.