The future of the python cookbook


#1

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


#2

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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net 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


#3

Erm, I am? The new cookbook is called “poise-python” as mentioned several times below.

–Noah

On Jul 18, 2015, at 9:01 PM, Nico Kadel-Garcia nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net 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


#4

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
nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net 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


#5

You are renaming it, and thank you for doing so. I realized only after sending it how much I failed to credit your thoughtful work, and you’ve my apology for that.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 19, 2015, at 0:10, “Noah Kantrowitz” noah@coderanger.net wrote:

Erm, I am? The new cookbook is called “poise-python” as mentioned several times below.

–Noah

On Jul 18, 2015, at 9:01 PM, Nico Kadel-Garcia nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net 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


#6

I’m afraid that the “multiple versions on the chef server” breaks down very badly very quickly. The backwards incompatible rewrites were most noticeable with the yum and mysql cookbooks are the prime ones, but minor such changes have happened with nagios, yumrepo, and tomcat in the last few years.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 19, 2015, at 13:31, “Sean OMeara” someara@chef.io wrote:

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
nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net 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


#7

I think what Sean is trying to say, is that it’s extremely simple to just
specify a particular version requirement in the metadata.rb of a cookbook
and no matter how you deploy your cookbooks (server/solo) you won’t have to
deal with this. If a new version breaks something then just specify a
version look in the cookbook that depends on it.

I use environments in my chef server to lock cookbook versions for all
cookbooks, and only ever update this after a full testing pass, which would
pick up any breakages like this. If something breaks then I specify the
version I need in the metadata.rb of the cookbook that broke. In this case
it wouldn’t matter if I then deployed via solo or server, the metadata.rb
version statement does it’s job.

On Mon, Jul 20, 2015 at 6:27 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I’m afraid that the “multiple versions on the chef server” breaks down
very badly very quickly. The backwards incompatible rewrites were most
noticeable with the yum and mysql cookbooks are the prime ones, but minor
such changes have happened with nagios, yumrepo, and tomcat in the last few
years.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 19, 2015, at 13:31, “Sean OMeara” someara@chef.io wrote:

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
nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net
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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com


#8

it is simple to lock cookbook versions, but it does not help with
situations like yum and mysql… unless you are willing to be locked out of
all new releases of other cookbooks that depend on these going forward,
which is not very realistic.

On Mon, Jul 20, 2015 at 9:54 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

I think what Sean is trying to say, is that it’s extremely simple to just
specify a particular version requirement in the metadata.rb of a cookbook
and no matter how you deploy your cookbooks (server/solo) you won’t have to
deal with this. If a new version breaks something then just specify a
version look in the cookbook that depends on it.

I use environments in my chef server to lock cookbook versions for all
cookbooks, and only ever update this after a full testing pass, which would
pick up any breakages like this. If something breaks then I specify the
version I need in the metadata.rb of the cookbook that broke. In this case
it wouldn’t matter if I then deployed via solo or server, the metadata.rb
version statement does it’s job.

On Mon, Jul 20, 2015 at 6:27 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I’m afraid that the “multiple versions on the chef server” breaks down
very badly very quickly. The backwards incompatible rewrites were most
noticeable with the yum and mysql cookbooks are the prime ones, but minor
such changes have happened with nagios, yumrepo, and tomcat in the last few
years.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 19, 2015, at 13:31, “Sean OMeara” someara@chef.io wrote:

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
nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net
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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com


#9

This is no different any other library dependencies of any other code. You
specify a lock if you need something to work and if your lock becomes an
issue further down the line you put in the work to update your code so the
lock isn’t required.

The point is the options are there to avoid unexpected breakages from
dependency updates so that you can deploy updates in a controlled fashion.
That doesn’t mean you don’t have to do any work to maintain your code.

On Sat, Aug 8, 2015 at 8:48 PM, Koert Kuipers koert@tresata.com wrote:

it is simple to lock cookbook versions, but it does not help with
situations like yum and mysql… unless you are willing to be locked out of
all new releases of other cookbooks that depend on these going forward,
which is not very realistic.

On Mon, Jul 20, 2015 at 9:54 AM, Yoshi Spendiff <
yoshi.spendiff@indochino.com> wrote:

I think what Sean is trying to say, is that it’s extremely simple to just
specify a particular version requirement in the metadata.rb of a cookbook
and no matter how you deploy your cookbooks (server/solo) you won’t have to
deal with this. If a new version breaks something then just specify a
version look in the cookbook that depends on it.

I use environments in my chef server to lock cookbook versions for all
cookbooks, and only ever update this after a full testing pass, which would
pick up any breakages like this. If something breaks then I specify the
version I need in the metadata.rb of the cookbook that broke. In this case
it wouldn’t matter if I then deployed via solo or server, the metadata.rb
version statement does it’s job.

On Mon, Jul 20, 2015 at 6:27 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

I’m afraid that the “multiple versions on the chef server” breaks down
very badly very quickly. The backwards incompatible rewrites were most
noticeable with the yum and mysql cookbooks are the prime ones, but minor
such changes have happened with nagios, yumrepo, and tomcat in the last few
years.

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On Jul 19, 2015, at 13:31, “Sean OMeara” someara@chef.io wrote:

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
nkadel@skyhookwireless.com 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: nkadel@gmail.com
Sent from iPhone

On Jul 17, 2015, at 14:46, “Noah Kantrowitz” noah@coderanger.net
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


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com


Yoshi Spendiff
Ops Engineer
Indochino
Mobile: +1 778 952 2025
Email: yoshi.spendiff@indochino.com