[COOK-3401] Add Option to 'make altinstall' After Compiling Python From Source#52
[COOK-3401] Add Option to 'make altinstall' After Compiling Python From Source#52tjcravey wants to merge 9 commits intopoise:masterfrom tjcravey:master
Conversation
recipes/pip.rb
Outdated
There was a problem hiding this comment.
This still seems like the wrong approach, if what you want is /usr/bin/python2.7, then the binary should be set to that. I don't like the duplication of having these twice when it should only matter for one. If what you want is the ability to manage multiple versions of Python with Chef then I think the best I can say is "stay tuned" :)
…nstall and instead changed binary for altinstall
README.md
Outdated
There was a problem hiding this comment.
Corrected in https://github.com/tjcravey/python/commit/b534eba022a33a61181e193845fb8c37b85b0515
Thanks!
|
You need to set a default value for install_type. |
There was a problem hiding this comment.
This feels like one too many variables to me - isn't it really just another install method - package, source, source-altinstall? Right now if you were to typo install_type you'd get a random command line passed into the make install step which might not fail, but leave you with a real headscratcher as to why Python's not where you thought it would be...
|
IMO we need coverage of altinstall in the tests - probably as simple as copying the existing source test and updating the attributes to do an altinstall. |
|
@tjcravey this cannot be merged cleanly. Could you please rebase? |
|
Hi there! Is there any way that I can help with this? I've actually been waiting for this method of installing python as well. Maybe this will just serve as a bump, but I'd be happy to do the rebase if that helps to move things along with this PR. Thanks! |
|
As it stands this cannot be merged until the default value for install_type is added. |
|
In the code that @tjcravey has currently, it looks like install_type is only used when install_method != 'package'. There's a check in the attributes that sets a default for install_type when not using the package install_method. Is that sufficient or are you thinking of maybe a different way of doing this? |
|
Yes, and if that is the case and install_type is not set, this code will fail. |
|
Ok, I think that makes sense. Then, more in line with what akiernan mentioned above, would something like this work better? I added a private recipe and have the source and source-altinstall recipes reuse that. This keeps the install_type attribute from being exposed at all to the end user (since that's not really something I'd imagine they should need to muck with). |
|
Closing in favor of #56 |
When using the source install option by setting the attribute node['python']['install_method'] as documented in the readme to 'source' the compiled binaries are installed with 'make install' which overwrites the OS's system python. For yum-based Linux distributions, this can be problematic because yum on current versions of RHEL and CentOS has dependencies on Python 2.6. The current default Python installed when only setting the node['python']['install_method'] to source is Python 2.7.5.
Installing with 'make altinstall' instead of 'make install' allows the new version of Python to be installed alongside the already installed version. Further, installing setuptools and pip with the altinstall'd binary allows python packages installed with the python_pip resource in this cookbook to target this version and virtualenvs created with the python_virtualenv resource in this cookbook are able to target this version with the interpreter attribute.