Jira (PUP-1082) pip provider should handle multiple pips/pythons

Liam Monahan (JIRA)

unread,

Jul 16, 2015, 3:11:16 PM7/16/15

to puppe...@googlegroups.com

Liam Monahan updated an issue

Puppet /

PUP-1082

pip provider should handle multiple pips/pythons

Change By:	Liam Monahan

The Pip provider should provide a way to specify the path to pip. This would allow people to manage multiple python installs, by point pointing to the one they want to install into.

In RHEL, this makes it easy to have a non-system python installed somewhere (ie: 2.7 or 3.x) and let puppet manage the python packages.

This is related to bug #15980. (related in the way that if you could provide the path to the pip binary, 15980 would have a workaround).

Add Comment

This message was sent by Atlassian JIRA (v6.4.5#64020-sha1:78acd6c)

drew j (JIRA)

unread,

Sep 2, 2016, 6:17:03 AM9/2/16

to puppe...@googlegroups.com

drew j commented on

PUP-1082

Re: pip provider should handle multiple pips/pythons

Hello,

This issue has been outstanding for almost three years and I wondered whether any movement has been made to resolve it?

As it currently stands, the pip provider for the Package resource can manage packages for the system installed version of pip. It's not possible to manage packages for virtualenvs, etc.

It would be nice if there was a method to pass in the path to the pip binary to use for operations related to this provider.

For example,

  package { $pkg_name:

    ensure   => present,

    provider => 'pip',

    pip_path => '/opt/myvirtualenv/venv/bin/pip',

To me, this seems like a useful enhancement of this package and will reduce the need for people to use Execs to get this to work correctly.

Thanks,
Drew

Add Comment

This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)

Thomas Kishel (JIRA)

unread,

Feb 24, 2017, 2:10:03 PM2/24/17

to puppe...@googlegroups.com

Thomas Kishel commented on

PUP-1082

Re: pip provider should handle multiple pips/pythons

This is a repeat of comments I've made elsewhere....

Reviewing our list of package providers, I identify two types of providers: single-instance and multiple-instance. For the single-instance providers, such as yum, there should be only one executable, and it should be in PATH. For multiple-instance providers, such as gem and pip, there could be n-number of instances, each with its own executable and none of them may be in PATH. We recognize this with our puppet_gem provider, which differs from the gem provider only in that it uses an absolute path for gemcmd (except on Windows).

The provider attribute of a package is, in practice, overloaded as a command attribute: but provider does not accept an absolute path. An optional command attribute for providers (as implemented in the Exec resource type) would support multiple-instance providers without requiring a custom provider type for each provider instance.

Note that implementing the command attribute to support multiple-instance packages via a specific command executable will require adding the command attribute to self.title_patterns in lib/puppet/type/package.rb to maintain uniqueness via a composite uniqueness key. For example: ['sinatra', 'gem', '/usr/bin/gem'].