[chef] Re: Re: The future of the python cookbook

[Sean OMeara < >]

Nico,

Your repeated citing of the yum and mysql rewrites (1.5 and 1.3 years
ago, respectively) as a reason to avoid Chef Server make no sense.

Chef Server has nothing to do with cookbooks breaking APIs on major
revisions. If anything, it's argument FOR using a server, since it
functions as an artifact repo that can host multiple cookbook versions
simultaneously. As you mentioned, you can use Berkshelf and the
metadata system to lock down a Chef Environment. The Chef Server lets
you have multiple environments so you can test changes in isolation
without disturbing production.

For the record, Noah is doing the right thing here.

The yum and mysql cookbooks should have went through a period of
backwards-compat + deprecation warning. I'm sorry that caused you
frustration. However, there *IS* a point where things need to change,
and major version numbers are the place to do it.

-s



On Sun, Jul 19, 2015 at 12:01 AM, Nico Kadel-Garcia
<
 >
 wrote:
> If you're going to flat- out break reverse compatibility, rename it. I had 
> major grief with the mostly avoidable incompatibilities of older yum, which 
> had the "yum::epel" recipe used by other major cookbooks, and splitting off 
> yum-epel without leaving a yum::epel just to call yum-epel for backwards 
> compatibility. And I'm afraid that the recent updates to "mysql", replacing 
> the default mysql configurator with a mere LWRP, broke even more. By moving 
> aside and hiding my.cnf from normal users, it broke socket based access and 
> all the  tools that used a default value or read /etc/my.cnf to find the 
> socket.
>
> The list if incompatible revised cookbooks is not small, and it's 
> de-stabilizing. It makes upgrades if any component with dependencies 
> unsafe, and forces admins to waste valuable testing resources and time.
>
> Frankly, it's yet another reason to avoid chef servers and use chefdk with 
> chef-solo. You can lock down Berksfile.lock and avoid mixed updates and old 
> dependencies from breaking your whole environment.
>
> Python is a critical system resource: please take the idea of renaming the 
> cookbook to avoid incompatibilities seruously.
>
> Nico Kadel-Garcia
> Email: 
> 
 
> Sent from iPhone
>
>> On Jul 17, 2015, at 14:46, "Noah Kantrowitz" 
>> <
 >
>>  wrote:
>>
>> Hi there everyone,
>>
>> I'm the current maintainer of the python cookbook on Supermarket, and have 
>> been working on a major upgrade for it over the past few weeks: 
>> https://github.com/poise/poise-python. The downside is this will break at ;
>> least some compatibility with the old cookbook. The new cookbook does not 
>> currently support installing from source, though this is planned in the 
>> same way as poise-ruby-build works. My migration plan is to release the 
>> new cookbook under the `poise-python` name, and then release a new version 
>> of the `python` cookbook that acts as a compat wrapper around the new 
>> code. This means `python_pip` will be an alias for `python_package` and 
>> the old `python::default` recipe will continue to work. It is highly 
>> recommended that you prepare to switch your dependencies to the new 
>> cookbook, as the old one (`python`) will be deprecated.
>>
>> On the positive note, poise-python adds long-requested features like 
>> multi-package installs, a resource for `pip install -r`, and better 
>> support for Python 3 and PyPy! You can check out the documentation for 
>> poise-python at https://github.com/poise/poise-python#quick-start. I ;
>> welcome any and all feedback on poise-python, especially about missing or 
>> insufficient features, or any questions about the deprecation/migration.
>>
>> tl;dr python cookbook is deprecated and being replaced by poise-python 
>> soon.
>>
>> --Noah
>>