[chef] Re: Re: How would I prevent python_pip from installing packages that are already installed?

[Fabien Delpierre < >]

Daniel,

Setting the version like:

python_pip 'package' do

  version 'x'

  ...

end

...sounds like something I should be able to figure out. I have a requirements file that looks like this:

package==version

And a long list of packages.

I'd just need to parse it to separate the package names from the desired versions, instead of what I'm doing now, which really is doing:

python_pip 'package==version' do

  ...

end

Maybe that's what I'm doing wrong to begin with, but since the conventional method to install a specific version is to do $ pip install package==version, I figured that doing it like I'm doing would pass the package==version directly to the python_pip resource and it would take care of itself fine.

I don't think submitting bugs is going to do anything since the maintainer(s) of the python cookbook have not quite abandoned it but keep saying they mean to gut it and redo the whole thing from the ground up, so... I dunno :) Anyway, I will try parsing my requirements file. It's funny because I'm refactoring the original code written by someone else, and they just had:

bash "install packages" do

  cwd "/foo"

  code "source venv/bin/activate; pip install -r setup/reqs.txt"

end

And I thought that was horribly inelegant, but I've spent more time getting this to work than I would have by leaving it alone. I'll have learned a few things by the time I'm done, though, so that's alright.

Thanks for the suggestion, I'll have to try it next week!

On Fri, Mar 6, 2015 at 5:07 PM, Daniel DeLeo < " target="_blank"> > wrote:

On Friday, March 6, 2015 at 10:29 AM, Fabien Delpierre wrote:
> Hello folks,
>
> I have the following bit of code:
>
> reqs.each do |req|
> python_pip req do
> virtualenv /foo
> action :upgrade
> not_if "ls -1 /foo/lib/python33/site-packages | grep #{req}"
> end
> end
>
> Now, reqs is a pretty large list of pip packages (probably about 30) compiled from a requirements file. Additionally, each package has a specific version requirement.
> So whenever Chef runs, it painstakingly attempts to upgrade every package listed in reqs despite my apparently feeble and incompetent not_if. It causes my Chef run to take 5-7 minutes instead of 2-3. This is fine for the first run, but this is a development VM for a team that iterates pretty fast, so 5-7 minute "compile times" are going to be a drag.
>
> One strange thing that might be relevant is that the Chef log reads something like the below line for each pip package:
>
> ==> default: [2015-03-06T13:02:05-05:00] INFO: Upgrading python_pip[alembic==0.6.4] version from uninstalled to latest
>
> Note that it says "uninstalled" even though the package is definitely installed.
> $ pip list
> pip (6.0.8)
> setuptools (12.4)
> virtualenv (12.0.7)
> $ source /foo/bin/activate
> (foo)$ pip list
> alembic (0.6.4)
> ...
> pip (6.0.8)
> ...
> setuptools (13.0.2)
> ...
> (foo)$
>
> Interestingly though, there is one package in reqs without a version requirement, it's gunicorn. When Chef tries to install it, it says this instead:
>
> ==> default: [2015-03-06T13:01:57-05:00] INFO: Upgrading python_pip[gunicorn] version from 19.3.0 to latest
>
> Frankly it shouldn't even be trying to install gunicorn anyway, but it's interesting/weird to me that for this one package, it accurately detects that it's installed and returns the installed version, whereas all the other ones report that they're uninstalled even though that's wrong.

All of these things sound like bugs, you should file an issue.
>
> The ls command in my not_if returns the correct code whether the virtual environment is active or not.
>
> $ ls -1 /foo/lib/python3.3/site-packages | grep alem; echo $?
> alembic
> alembic-0.6.4-py3.3.egg-info
> 0
> $ ls -1 /foo/lib/python3.3/site-packages | grep foo; echo $?
> 1
>
> So unless I'm off the mark with my logic, the python_pip resource should execute only if grep returns 1... but that's not the case and I'm confused and help please pretty please with powdered sugar and a cherry on top.
Since you know the version you want, have you tried setting the version on the package resource and specifying `action :install` ? Including the desired version makes the install action behave like upgrade or downgrade if your existing version isn’t the desired one (modulo weirdness in the underlying packager’s implementation, for example rpm needs an extra flag to allow downgrades). It may be that the pip provider is just naive and doesn’t yet support this functionality, in which case that would be a separate bug to file.

>
> Thanks in advance!
> Fabien



--
Daniel DeLeo