Skip to content
This repository has been archived by the owner on Jun 18, 2019. It is now read-only.

Add a provider to support installing from source #58

Open
colbywhite opened this issue May 20, 2016 · 6 comments
Open

Add a provider to support installing from source #58

colbywhite opened this issue May 20, 2016 · 6 comments

Comments

@colbywhite
Copy link

If you are using ubuntu and the :system provider (i.e. apt-get), you will be relegated to the version that is in the apt-get repositories. And the apt-get repositories are usually behind the latest. For instance, right now apt-cache policy python2.7 says 2.7.6 is the latest version, but 2.7.11 is actually the latest.

Installing from apt-get also has the downside of not being great at installing older versions. I believe if you wanted 2.7.4, you would have to find a repo with it and add it. And this cookbook doesn't do that (which it probably shouldn't).

I think installing from source solves this problem. It does have the downside of taking more time, but it'll give the ability to support a wider range of versions on ubuntu, i.e. any version that is on the python.org page. (The :scl provider looks like it would support a wider range of versions, but it doesn't support ubuntu and I'm not familiar enough with softwarecollections.org to know if it's easy to support ubuntu.)

So, I'm thinking a :source provider would do the trick. The recipe for installing from source is pretty straightforward. It'll just need the version/checksums added as parameters/attributes. The more time-consuming part would likely be the testing (particularly for someone like me who isn't an expert on chef testing, but that's partially why I want to do this).

ark 'python' do
  version '2.7.11'
  url 'https://www.python.org/ftp/python/2.7.11/Python-2.7.11.tgz'
  action :install_with_make
end

Thoughts? If agreed, I will attempt to start adding the provider some time next week when I get time.

@dmerrick
Copy link

I think this would be great! I am trying to install Python 3.5 on Ubuntu and it's not available in apt yet.

Source was also available on the old python cookbook, so it would be nice to have it here as well.

@coderanger
Copy link
Member

The plan is to port things over from the poise-ruby-build cookbook but using python-build instead of ruby. Just haven't had the cycles.

@dmerrick
Copy link

Ah thanks, I just found this in the README and was coming to post it here:

At this time there is no provider to install from source so there is no replacement for the python::source recipe, however this is planned for the future via a python-build provider.

In the meantime, do you have a suggestion for getting python 3.5 installed? Perhaps I should add the deadsnakes ppa by hand, and then run my python_runtime resource?

@coderanger
Copy link
Member

Yep, the fallback is to install Python via your own recipe via whatever means you want, and then use the dummy provider:

python_runtime '3.5' do
  provider :dummy
  options python_binary: '/path/to/python'
end

and then everything will just work :)

@dnfehren
Copy link

dnfehren commented Apr 27, 2017

adding that dummy provider as a note in the docs would be really useful.

Also, I've been working on a provider to install python from a custom Debian package that we serve from an internal repository and ran in to a really frustrating situation where the apt_package resource wouldn't use the value of the package_version key in options. Creating a copy seemed to fix it, but it took a while to figure out. If other people are trying to install custom pythons in a apt-based distribution they might run into this as well.

Likely there isn't a workaround in this cookbook specifically, but wanted to put the note somewhere.

class SproutPyProvider < PoisePython::PythonProviders::System
    provides(:sproutpy)

    def install_python

        py_version = options['package_version']

        apt_package 'sproutpy' do
            version py_version
        end
        package 'python-dev'
    end

    def python_binary
        "/opt/sproutpy/bin/python"
    end

end

@coderanger
Copy link
Member

coderanger commented Apr 27, 2017

@dnfehren The problem is that the options method from the provider conflicts with the options property on the apt_package resource. So what you have there is correct (or you could do something like _options = options and then use _options['package_version'] below if there was more than one value you needed). Unfortunately just a quirk of Ruby and Chef's method scoping.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants