Issue #15980 has been updated by Kamil Wilas.
It is not really "default". There is a few scenarios which help me describe my
idea:
1. I've installed pip-python from epel. I don't have pip from easy_install.
Puppet pip provider use pip-python.
2. I've installed pip from easy_install. I don't have pip-python from epel.
Puppet pip provider use pip.
3. I've both pip from easy_install and pip-python from epel installed. Puppet
pip provider use pip, because it is newer version of pip and probably reason
why pip was installed by easy_install was because we want/need newer version.
If someone create newer rpm package with pip-python then probably that person
won't install pip by easy_install.
I as sysadmin can decide what provider I want use on my RHEL box by installing
proper version of pip (from repo or by easy-install) so there is not default
version. There is maybe promoted version because is newer.
There are two reasons why I decide remove cmd method:
1. to simplify code - why should we keep not used method, it may make only some
problems and code is less readable? We also need keep tests for that method. I
think when method will be needed then we can create it. I think it won't be
needed. I will try explain my idea in next step :)
2. if in future adding new pip command for specific OS will be needed (e.g.
pip-python3, pip-future, ...) then enough is add line like this:
pip_cmd ||= which('pip-python3') in proper place to
lib/puppet/provider/package/pip.rb. We don't have to thinking about OS.
Example (given future_OS) and future_code (may be different order - maybe in
future other solution will be promoted):
pip_cmd ||= which('pip')
pip_cmd ||= which('pip-python')
pip_cmd ||= which('pip-python3')
pip_cmd ||= which('pip-future')
mean if we have pip command on future_OS (we have installed proper package)
then we use pip, otherwise
if we have pip-python command on future_OS (we have installed proper package)
then we use pip-python, otherwise...
So same story as I write above. I as sysadmin given box can decide what pip
version should the puppet pip provider use. The pip provider only allow me to
do something like this (is enough flexible).
----------------------------------------
Bug #15980: pip provider nonfunctional on redhat-based systems
https://projects.puppetlabs.com/issues/15980#change-83436
Author: Eric Shamow
Status: Re-opened
Priority: Normal
Assignee: Jeff McCune
Category: provider
Target version: 3.1.x
Affected Puppet version: 2.6.17
Keywords: pip
Branch: https://github.com/puppetlabs/puppet/pull/1348
RHEL installs this binary as pip-python, and the pip provider looks explicitly
for a 'pip' binary.
Current workaround is a symlink file resource to create the binary, but this
should work out of the box.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" 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-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
