::File notation


#1

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do
block do
log "testing resource group"
file “/tmp/test1” do
mode "0600"
end

end
action :nothing
notifies :write, "log[test]"
only_if { ::File.exists? “/tmp/test2” }
end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#2

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
log “testing resource group”

  file "/tmp/test1" do

  	mode "0600"

  end

end
action :nothing

notifies :write, “log[test]”

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#3

Yep, the issue is that recipe code is executed in the Chef::Recipe namespace, so “File” gets you Chef::File. Not sure there is a workaround given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
log “testing resource group”

  file "/tmp/test1" do

  	mode "0600"

  end

end
action :nothing

notifies :write, “log[test]”

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#4

So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe namespace, so “File” gets you Chef::File. Not sure there is a workaround given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#5

I think he is just stating that this is subpar, which is true. It is definitely a place a lot of new Chef users get caught up, so maybe we should consider renaming the Chef class so it doesn’t conflict, at which point the name would resolve normally. This would require special-casing something somewhere I think, but perhaps it is worth it?

–Noah

On Apr 16, 2013, at 10:52 AM, Mike wrote:

So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe namespace, so “File” gets you Chef::File. Not sure there is a workaround given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
log “testing resource group”

       file "/tmp/test1" do

               mode "0600"

       end

end
action :nothing

notifies :write, “log[test]”

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#6

Mike, take a note that recipe authors aren’t ruby pro’s (more
administrators than programmers). So we need to keep recipe syntax as
simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No namespace
collision issue in mind.

2013/4/16 Mike miketheman@gmail.com

So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe
namespace, so “File” gets you Chef::File. Not sure there is a workaround
given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root
namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#7

Make a patch and open a ticket and I’m sure btm and crew will be glad to take a look :slight_smile: It might need to wait for a major release since it would be a backwards-incompatible change, but this would only affect people subclassing the file resource I think, which should be somewhat rare so maybe we can just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more administrators than programmers). So we need to keep recipe syntax as simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No namespace collision issue in mind.

2013/4/16 Mike miketheman@gmail.com
So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe namespace, so “File” gets you Chef::File. Not sure there is a workaround given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#8

Noah, I suppose that it MUST be a choice of core team. This is a missed
usability issue.

2013/4/16 Noah Kantrowitz noah@coderanger.net

Make a patch and open a ticket and I’m sure btm and crew will be glad to
take a look :slight_smile: It might need to wait for a major release since it would be
a backwards-incompatible change, but this would only affect people
subclassing the file resource I think, which should be somewhat rare so
maybe we can just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more
administrators than programmers). So we need to keep recipe syntax as
simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No
namespace collision issue in mind.

2013/4/16 Mike miketheman@gmail.com
So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe
namespace, so “File” gets you Chef::File. Not sure there is a workaround
given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root
namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#9

BTW, I was writing my thoughts on this and fired up chef-shell to try it.
And guess what, this works like a charm in recipe_mode without any ::

chef:recipe > file “test” do
chef:recipe > not_if { File.exists?(“test”) }
chef:recipe ?> end

Are we even sure this is still a problem or are we cargo-culting something
that is in the past?!

On Tue, Apr 16, 2013 at 8:31 PM, Akzhan Abdulin akzhan.abdulin@gmail.comwrote:

Noah, I suppose that it MUST be a choice of core team. This is a missed
usability issue.

2013/4/16 Noah Kantrowitz noah@coderanger.net

Make a patch and open a ticket and I’m sure btm and crew will be glad to
take a look :slight_smile: It might need to wait for a major release since it would be
a backwards-incompatible change, but this would only affect people
subclassing the file resource I think, which should be somewhat rare so
maybe we can just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more
administrators than programmers). So we need to keep recipe syntax as
simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No
namespace collision issue in mind.

2013/4/16 Mike miketheman@gmail.com
So we’re back to me not understanding the problem that Akzhan is
stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe
namespace, so “File” gets you Chef::File. Not sure there is a workaround
given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root
namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#10

Works for me

chef > recipe_mode
chef:recipe > log “File works without having to prefix the root namespace” do
chef:recipe > only_if do
chef:recipe > File.exists? "/tmp"
chef:recipe ?> end
chef:recipe ?> end
=> <log[File works without having to prefix the root namespace]
@name: “File works without having to prefix the root namespace” @noop:
nil @before: nil @params: {} @provider: nil @allowed_actions:
[:nothing] @action: :write @updated: false @updated_by_last_action:
false @supports: {} @ignore_failure: false @retries: 0 @retry_delay: 2
@source_line: “(irb#1):1:in `irb_binding’” @elapsed_time: 0
@resource_name: :log @level: :info @message: “File works without
having to prefix the root namespace” @cookbook_name: nil @recipe_name:
nil>
chef:recipe > run_chef
[2013-04-17T09:12:22+12:00] INFO: Processing log[File works without
having to prefix the root namespace] action write ((irb#1) line 1)
[2013-04-17T09:12:22+12:00] INFO: File works without having to prefix
the root namespace
=> true

/thread

On 17 April 2013 08:37, Andrea Campi andrea.campi@zephirworks.com wrote:

BTW, I was writing my thoughts on this and fired up chef-shell to try it.
And guess what, this works like a charm in recipe_mode without any ::

chef:recipe > file “test” do
chef:recipe > not_if { File.exists?(“test”) }
chef:recipe ?> end

Are we even sure this is still a problem or are we cargo-culting something
that is in the past?!

On Tue, Apr 16, 2013 at 8:31 PM, Akzhan Abdulin akzhan.abdulin@gmail.com
wrote:

Noah, I suppose that it MUST be a choice of core team. This is a missed
usability issue.

2013/4/16 Noah Kantrowitz noah@coderanger.net

Make a patch and open a ticket and I’m sure btm and crew will be glad to
take a look :slight_smile: It might need to wait for a major release since it would be a
backwards-incompatible change, but this would only affect people subclassing
the file resource I think, which should be somewhat rare so maybe we can
just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more
administrators than programmers). So we need to keep recipe syntax as simple
as can.

File.exists? phrase is more intuitive than ::File.exists? one. No
namespace collision issue in mind.

2013/4/16 Mike miketheman@gmail.com
So we’re back to me not understanding the problem that Akzhan is
stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe
namespace, so “File” gets you Chef::File. Not sure there is a workaround
given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root
namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system
ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#11

Good to hear it. I was not tested it yet :slight_smile:

2013/4/17 Andrea Campi andrea.campi@zephirworks.com

BTW, I was writing my thoughts on this and fired up chef-shell to try it.
And guess what, this works like a charm in recipe_mode without any ::

chef:recipe > file “test” do
chef:recipe > not_if { File.exists?(“test”) }
chef:recipe ?> end

Are we even sure this is still a problem or are we cargo-culting something
that is in the past?!

On Tue, Apr 16, 2013 at 8:31 PM, Akzhan Abdulin akzhan.abdulin@gmail.comwrote:

Noah, I suppose that it MUST be a choice of core team. This is a missed
usability issue.

2013/4/16 Noah Kantrowitz noah@coderanger.net

Make a patch and open a ticket and I’m sure btm and crew will be glad to
take a look :slight_smile: It might need to wait for a major release since it would be
a backwards-incompatible change, but this would only affect people
subclassing the file resource I think, which should be somewhat rare so
maybe we can just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more
administrators than programmers). So we need to keep recipe syntax as
simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No
namespace collision issue in mind.

2013/4/16 Mike miketheman@gmail.com
So we’re back to me not understanding the problem that Akzhan is
stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz noah@coderanger.net
wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe
namespace, so “File” gets you Chef::File. Not sure there is a workaround
given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root
namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
akzhan.abdulin@gmail.com wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system
ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom avishai@fewbytes.com

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#12

Yeah – I’m not clear this is a problem in the vast majority of cases.

Adam

From: Andrea Campi [mailto:andrea.campi@zephirworks.com]
Sent: Tuesday, April 16, 2013 1:38 PM
To: Akzhan Abdulin
Cc: Noah Kantrowitz; Mike; Avishai Ish-Shalom; Chef Dev
Subject: [chef-dev] Re: Re: Re: Re: ::File notation

BTW, I was writing my thoughts on this and fired up chef-shell to try it.
And guess what, this works like a charm in recipe_mode without any ::

chef:recipe > file “test” do
chef:recipe > not_if { File.exists?(“test”) }
chef:recipe ?> end

Are we even sure this is still a problem or are we cargo-culting something that is in the past?!

On Tue, Apr 16, 2013 at 8:31 PM, Akzhan Abdulin <akzhan.abdulin@gmail.commailto:akzhan.abdulin@gmail.com> wrote:
Noah, I suppose that it MUST be a choice of core team. This is a missed usability issue.

2013/4/16 Noah Kantrowitz <noah@coderanger.netmailto:noah@coderanger.net>
Make a patch and open a ticket and I’m sure btm and crew will be glad to take a look :slight_smile: It might need to wait for a major release since it would be a backwards-incompatible change, but this would only affect people subclassing the file resource I think, which should be somewhat rare so maybe we can just put out a warning.

–Noah

On Apr 16, 2013, at 11:25 AM, Akzhan Abdulin wrote:

Mike, take a note that recipe authors aren’t ruby pro’s (more administrators than programmers). So we need to keep recipe syntax as simple as can.

File.exists? phrase is more intuitive than ::File.exists? one. No namespace collision issue in mind.

2013/4/16 Mike <miketheman@gmail.commailto:miketheman@gmail.com>
So we’re back to me not understanding the problem that Akzhan is stating.

On Tue, Apr 16, 2013 at 1:51 PM, Noah Kantrowitz <noah@coderanger.netmailto:noah@coderanger.net> wrote:

Yep, the issue is that recipe code is executed in the Chef::Recipe namespace, so “File” gets you Chef::File. Not sure there is a workaround given Ruby’s structure for name lookups.

–Noah

On Apr 16, 2013, at 10:18 AM, Mike wrote:

I don’t understand.

By using ::File, aren’t you guaranteeing that you’re using the root namespace?

On Tue, Apr 16, 2013 at 12:56 PM, Akzhan Abdulin
<akzhan.abdulin@gmail.commailto:akzhan.abdulin@gmail.com> wrote:

Hello Chiefs,

I have insight, - Chef classes should never be named as system ones.

We need to eliminate ::File and so on notation.

Yours sincerely,
Akzhan.

2013/4/16 Avishai Ish-Shalom <avishai@fewbytes.commailto:avishai@fewbytes.com>

inline_recipe “test” do

block do
        log "testing resource group"

        file "/tmp/test1" do

                mode "0600"

        end
end
action :nothing

notifies :write, "log[test]"

only_if { ::File.exists? “/tmp/test2” }

end

https://github.com/avishai-ish-shalom/chef-inline-recipe/blob/master/recipes/default.rb


#13

Adam,

I suspect that this is an annoyance for programmers who are fluent in Ruby
and who want to write providers.

For example, if a provider requires reading a cache file in
load_current_resource, the normal expectation is that
File.read(cache_file_path) should work. It works in most other Ruby code,
and programmers who are fluent in Ruby will have written that same line
hundreds of times before. There is a perfectly sensible and easily
comprehended reason why it doesn’t this time, and there is a perfectly
sensible and easily comprehended workaround with either ::File or IO.

This is not a blocker. But it is a speed bump.

In the name of avoiding all such speed bumps, the resource class could have
been named Chef::Resource::FileResource and the provider class
Chef::Provider::FileProvider. The same pattern could have been extended
to all resource and provider classes as well.

Cheers,
Jay

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob adam@opscode.com wrote:

Yeah – I’m not clear this is a problem in the vast majority of cases.****


Adam****

**


#14

Why wouldn’t you then call it Chef::ProviderChef::FileProviderChef and
Chef::ResourceChef::FileResourceChef?

It just seems a bit redundant… perhaps it would be better if LWRPs did
not automatically inherit the Chef::Provider and Chef::Resource namespaces?

On Wed, Apr 17, 2013 at 2:18 PM, Jay Feldblum y_feldblum@yahoo.com wrote:

Adam,

I suspect that this is an annoyance for programmers who are fluent in Ruby
and who want to write providers.

For example, if a provider requires reading a cache file in
load_current_resource, the normal expectation is that
File.read(cache_file_path) should work. It works in most other Ruby code,
and programmers who are fluent in Ruby will have written that same line
hundreds of times before. There is a perfectly sensible and easily
comprehended reason why it doesn’t this time, and there is a perfectly
sensible and easily comprehended workaround with either ::File or IO.

This is not a blocker. But it is a speed bump.

In the name of avoiding all such speed bumps, the resource class could
have been named Chef::Resource::FileResource and the provider class
Chef::Provider::FileProvider. The same pattern could have been extended
to all resource and provider classes as well.

Cheers,
Jay

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob adam@opscode.com wrote:

Yeah – I’m not clear this is a problem in the vast majority of cases.***
*


Adam****

**


#15

I felt the same way - I have no desire to see Resource and Provider tacked on the end of everything.

Adam

From: Jesse Campbell [mailto:hikeit@gmail.com]
Sent: Wednesday, April 17, 2013 2:27 PM
To: Jay Feldblum
Cc: Chef Dev
Subject: [chef-dev] Re: Re: RE: Re: Re: Re: Re: ::File notation

Why wouldn’t you then call it Chef::ProviderChef::FileProviderChef and Chef::ResourceChef::FileResourceChef?
It just seems a bit redundant… perhaps it would be better if LWRPs did not automatically inherit the Chef::Provider and Chef::Resource namespaces?

On Wed, Apr 17, 2013 at 2:18 PM, Jay Feldblum <y_feldblum@yahoo.commailto:y_feldblum@yahoo.com> wrote:
Adam,

I suspect that this is an annoyance for programmers who are fluent in Ruby and who want to write providers.

For example, if a provider requires reading a cache file in load_current_resource, the normal expectation is that File.read(cache_file_path) should work. It works in most other Ruby code, and programmers who are fluent in Ruby will have written that same line hundreds of times before. There is a perfectly sensible and easily comprehended reason why it doesn’t this time, and there is a perfectly sensible and easily comprehended workaround with either ::File or IO.

This is not a blocker. But it is a speed bump.

In the name of avoiding all such speed bumps, the resource class could have been named Chef::Resource::FileResource and the provider class Chef::Provider::FileProvider. The same pattern could have been extended to all resource and provider classes as well.

Cheers,
Jay

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob <adam@opscode.commailto:adam@opscode.com> wrote:
Yeah - I’m not clear this is a problem in the vast majority of cases.

Adam


#16

I think a small paragraph regarding constant name-spacing in Ruby would suffice in the “just enough Ruby for Chef guide”. This should be accompanied with an example of a frequent gotcha; i.e. File.read.

This was of no surprise or annoyance to me when I began working with Chef because I had been programming Ruby for years beforehand. If I hadn’t known how Ruby constant name-spacing worked I probably would have been quite aggravated and this and it would have been compounded further since testing cookbooks is now just becoming a reality.


Jamie Winsor
@resetexistence

On Thursday, April 18, 2013 at 12:24 PM, Adam Jacob wrote:

I felt the same way – I have no desire to see Resource and Provider tacked on the end of everything.

Adam

From: Jesse Campbell [mailto:hikeit@gmail.com]
Sent: Wednesday, April 17, 2013 2:27 PM
To: Jay Feldblum
Cc: Chef Dev
Subject: [chef-dev] Re: Re: RE: Re: Re: Re: Re: ::File notation

Why wouldn’t you then call it Chef::ProviderChef::FileProviderChef and Chef::ResourceChef::FileResourceChef?

It just seems a bit redundant… perhaps it would be better if LWRPs did not automatically inherit the Chef::Provider and Chef::Resource namespaces?

On Wed, Apr 17, 2013 at 2:18 PM, Jay Feldblum <y_feldblum@yahoo.com (mailto:y_feldblum@yahoo.com)> wrote:

Adam,

I suspect that this is an annoyance for programmers who are fluent in Ruby and who want to write providers.

For example, if a provider requires reading a cache file in load_current_resource, the normal expectation is that File.read(cache_file_path) should work. It works in most other Ruby code, and programmers who are fluent in Ruby will have written that same line hundreds of times before. There is a perfectly sensible and easily comprehended reason why it doesn’t this time, and there is a perfectly sensible and easily comprehended workaround with either ::File or IO.

This is not a blocker. But it is a speed bump.

In the name of avoiding all such speed bumps, the resource class could have been named Chef::Resource::FileResource and the provider class Chef::Provider::FileProvider. The same pattern could have been extended to all resource and provider classes as well.

Cheers,

Jay

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob <adam@opscode.com (mailto:adam@opscode.com)> wrote:

Yeah – I’m not clear this is a problem in the vast majority of cases.

Adam


#17

To give a newb perspective: When I first encountered this I was horribly
confused and didn’t know what was wrong. But I went out and read a few
other LWRPs and found a pattern that worked for me and just used it
without really understanding.

I wasn’t annoyed though. I just figured I was dumb and that’s how you
had to use File in resources.

By the way, I’d like to thank Fletcher and Bryan for writing great
resources and libraries in chef-rvm and ark which were my main early
references when writing lwrp code.

Sascha

Jamie Winsor wrote:

I think a small paragraph regarding constant name-spacing in Ruby
would suffice in the “just enough Ruby for Chef guide”. This should be
accompanied with an example of a frequent gotcha; i.e. File.read.

This was of no surprise or annoyance to me when I began working with
Chef because I had been programming Ruby for years beforehand. If I
hadn’t known how Ruby constant name-spacing worked I probably would
have been quite aggravated and this and it would have been compounded
further since testing cookbooks is now just becoming a reality.


Jamie Winsor
@resetexistence
https://github.com/reset

On Thursday, April 18, 2013 at 12:24 PM, Adam Jacob wrote:

I felt the same way – I have no desire to see Resource and Provider
tacked on the end of everything.

Adam

*From:*Jesse Campbell [mailto:hikeit@gmail.com]
Sent: Wednesday, April 17, 2013 2:27 PM
To: Jay Feldblum
Cc: Chef Dev
Subject: [chef-dev] Re: Re: RE: Re: Re: Re: Re: ::File notation

Why wouldn’t you then call it Chef::ProviderChef::FileProviderChef
and Chef::ResourceChef::FileResourceChef?

It just seems a bit redundant… perhaps it would be better if LWRPs
did not automatically inherit the Chef::Provider and Chef::Resource
namespaces?

On Wed, Apr 17, 2013 at 2:18 PM, Jay Feldblum <y_feldblum@yahoo.com
mailto:y_feldblum@yahoo.com> wrote:

Adam,

I suspect that this is an annoyance for programmers who are
fluent in Ruby and who want to write providers.

For example, if a provider requires reading a cache file in
load_current_resource, the normal expectation is that
File.read(cache_file_path) should work. It works in most other
Ruby code, and programmers who are fluent in Ruby will have
written that same line hundreds of times before. There is a
perfectly sensible and easily comprehended reason why it doesn't
this time, and there is a perfectly sensible and easily
comprehended workaround with either ::File or IO.

This is not a blocker. But it is a speed bump.

In the name of avoiding all such speed bumps, the resource class
could have been named `Chef::Resource::FileResource` and the
provider class `Chef::Provider::FileProvider`. The same pattern
could have been extended to all resource and provider classes as
well.

Cheers,

Jay

On Wed, Apr 17, 2013 at 11:51 AM, Adam Jacob <adam@opscode.com
<mailto:adam@opscode.com>> wrote:

    Yeah – I’m not clear this is a problem in the vast majority
    of cases.

    Adam