In resolving bug 15980, the pip package provider was changed to recognize the RedHat osfamily fact and use the executable name "pip-python" in those environments. This does not take into account environments where pip has been installed via easy_install or by custom rpm providers. In those environments (such as mine) this osfamily change breaks the pip provider, requiring as a workaround that the administrator create a softlink to pip-python before any pip packages are referenced.
It seems to me that the change could have been accomplished by trying the pip-python alias if the normal exe name failed, rather than assuming that the weird way that one common RPM names pip is a global circumstance. Obviously I already discovered the workaround and the problem, so I suppose I'm just posting this in the hopes that it shows up in a Google search for the next guy. Thanks. -- M -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
