Exec[bootstrap pip] Executes Every Puppet Run

[johnzimm]

I have the following code snippet..

  class { 'python':
    version    => 'system',
    pip        => 'latest',
    provider   => 'pip',
    dev        => 'present',
    virtualenv => 'present',
    gunicorn   => 'absent',
  }

And I get the following on every puppet run...

Notice: /Stage[main]/Python::Install/Exec[bootstrap pip]/returns: executed successfully
Notice: /Stage[main]/Python::Install/Package[pip]/ensure: created

Because the get-pip.py script puts the executable for pip in /bin/pip rather than /usr/local/bin/pip as specified in the install.pp manifest...

https://github.com/stankevich/puppet-python/blob/master/manifests/install.pp#L74

Applying to CentOS 7. Not sure if this is the same for other distros.

[johnzimm]

After manually creating a symlink /usr/local/bin/pip to /bin/pip the Exec[bootstrap pip] notice stops as expected.

However the Package[pip] notice still displays...

Notice: /Stage[main]/Python::Install/Package[pip]/ensure: created

One possible reason might be that the pip provider for the package resource might use pip freeze instead of pip list.

pip freeze doesn't appear to list pip itself or setup_tools, but pip list does.

[cwood]

I am having this same issue as well.

[ChrisPortman]

Im having the same issue. The exec:

exec { 'bootstrap pip':
    command => '/usr/bin/curl https://bootstrap.pypa.io/get-pip.py | python',
    creates => '/usr/local/bin/pip',
    require => Package['python'],
}

Unfortunately the command does not create /usr/local/bin/pip (but rather /bin/pip). I have silenced it with:

exec{ 'Hack the python boostrap idempotency issue':
    command     => '/bin/ln -s /bin/pip /usr/local/bin/pip',
    refreshonly => true,
    subscribe   => Exec['bootstrap pip'],
}

Which has stopped it running over and over again. the refreshonly and subscribe ensures that this new exec will only run when the bootstrap one does and the bootstrap one should not run after the new exec has.

[asasfu]

I wrote up a quick PR for this to support /bin/pip, /usr/bin/pip and /usr/local/bin/pip as it definitely picks /usr/bin/pip on Centos 7. I have not tested Fedora or other Redhat flavours but this would support any OS as they tend to pick either /usr/bin/pip or /usr/local/bin/pip.

The constant pip ensure: created was due to provider/package/pip.rb not supporting understanding that pip freeze does not include pip. In 4.5.0 that was finally fixed in the provider. Puppet 4.5.0 PIP-6120

PR: #318

[gdubicki]

(Nvm, I put my comment in the wrong ticket, sorry)