# Why is my windows\_package source attribute getting mucked up?

**URL:** <https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264>\
**Category:** Chef Infra (archive)\
**Created:** [February 6, 2015, 8:29pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264 "2015-02-06T20:29:43Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_F](https://avatars.discourse-cdn.com/v4/letter/c/fbc32d/32.png) [@Chris\_F](https://discourse.chef.io/u/Chris_F)\
**Post date:** [February 6, 2015, 8:29pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/1 "2015-02-06T20:29:43Z")

</div>

I have the following resource

windows\_package “Install App1” do  
source "{node.cookbook.package\_url}"  
action :install  
end

In my case, node.cookbook.package\_url = [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)

Chef chef-client run fails, and error message shows the source attribute as  
"C:\http:\[file-server-domain.com](http://file-server-domain.com)\path\app1.msi"

If I remove the windows\_package and just use the log resource, I see the correct format. That is

log “{node.cookbook.package\_url}”

I see

INFO: [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)

What am I missing?

Chris

---

<div class="post-metadata">

**Author:** ![Justin\_Dossey](https://avatars.discourse-cdn.com/v4/letter/j/e19b73/32.png) [@Justin\_Dossey](https://discourse.chef.io/u/Justin_Dossey)\
**Post date:** [February 6, 2015, 11:41pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/2 "2015-02-06T23:41:11Z")

</div>

source needs to be a path to a local file. Since you're instead giving it  
a URL, the resource provider interprets the URL as a path, which is (of  
course) wrong. You could use remote\_file to download the URL to a  
temporary location beforehand.

On Fri, Feb 6, 2015 at 12:29 PM, Fouts, Chris [Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)  
wrote:

> I have the following resource
> 
> windows\_package “Install App1” do
> 
> source “{node.cookbook.package\_url}”
> 
> action :install
> 
> end
> 
> In my case, node.cookbook.package\_url =  
> [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)
> 
> Chef chef-client run fails, and error message shows the source attribute  
> as
> 
> “C:\http:\file-server-domain.com\path\app1.msi”
> 
> If I remove the windows\_package and just use the log resource, I see the  
> correct format. That is
> 
> log “{node.cookbook.package\_url}”
> 
> I see
> 
> INFO: [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)
> 
> What am I missing?
> 
> Chris

--  
Justin Dossey  
Practice Owner  
New Context Services, Inc

---

<div class="post-metadata">

**Author:** ![Chris\_F](https://avatars.discourse-cdn.com/v4/letter/c/fbc32d/32.png) [@Chris\_F](https://discourse.chef.io/u/Chris_F)\
**Post date:** [February 10, 2015, 10:46pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/3 "2015-02-10T22:46:36Z")

</div>

More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.

Chris

From: Justin Dossey [[mailto:justin.dossey@newcontext.com](mailto:justin.dossey@newcontext.com)]  
Sent: Friday, February 06, 2015 6:41 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: Why is my windows\_package source attribute getting mucked up?

source needs to be a path to a local file. Since you’re instead giving it a URL, the resource provider interprets the URL as a path, which is (of course) wrong. You could use remote\_file to download the URL to a temporary location beforehand.

On Fri, Feb 6, 2015 at 12:29 PM, Fouts, Chris \<[Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)[mailto:Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)\> wrote:  
I have the following resource

windows\_package “Install App1” do  
source “{node.cookbook.package\_url}”  
action :install  
end

In my case, node.cookbook.package\_url = [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)

Chef chef-client run fails, and error message shows the source attribute as  
“C:\http:\[file-server-domain.com](http://file-server-domain.com)[http://file-server-domain.com](http://file-server-domain.com)\path\app1.msi”

If I remove the windows\_package and just use the log resource, I see the correct format. That is

log “{node.cookbook.package\_url}”

I see

INFO: [http://file-server.domain.com/path/app1.msi](http://file-server.domain.com/path/app1.msi)

What am I missing?

Chris

–  
Justin Dossey  
Practice Owner  
New Context Services, Inc

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [February 11, 2015, 5:07pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/4 "2015-02-11T17:07:39Z")

</div>

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

> More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.
> 
> Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Chris\_F](https://avatars.discourse-cdn.com/v4/letter/c/fbc32d/32.png) [@Chris\_F](https://discourse.chef.io/u/Chris_F)\
**Post date:** [February 12, 2015, 3:47pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/5 "2015-02-12T15:47:18Z")

</div>

I disagree.

winodow\_package "could" have been written such that when the source is a URL (http://), it would do a remote\_file first, and then execute the local package, all underneath the covers. Then its behavior is in-line with the package resource.

Chris

-----Original Message-----  
From: Daniel DeLeo [[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)] On Behalf Of Daniel DeLeo  
Sent: Wednesday, February 11, 2015 12:08 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: RE: Re: Why is my windows\_package source attribute getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

> More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.
> 
> Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Lamont\_Granquist](https://avatars.discourse-cdn.com/v4/letter/l/d26b3c/32.png) [@Lamont\_Granquist](https://discourse.chef.io/u/Lamont_Granquist)\
**Post date:** [February 12, 2015, 4:17pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/6 "2015-02-12T16:17:19Z")

</div>

On 2/12/15 7:47 AM, Fouts, Chris wrote:

> On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:
> 
> > More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.
> > 
> > Chris  
> > I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.  
> > Also on par with AIX which has RPM package, but lacks yum support. We do  
> > better support distros that make things easier. There's also a ton of  
> > contributed code in the yum and apt providers that is user contributed.

---

<div class="post-metadata">

**Author:** ![werebus](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/werebus/32/24_2.png) [@werebus](https://discourse.chef.io/u/werebus)\
**Post date:** [February 12, 2015, 4:42pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/7 "2015-02-12T16:42:48Z")

</div>

After looking around a little bit, I actually can’t see any evidence that  
any of the \_package resources can take an http “source” with the exception  
of “gem\_package”. The standard way to go about this if you can’t use the  
OS’s built-in package manager is to retrieve the file with remote\_file and  
then install it. You’re pretty-much just running up against “Linux, BSD,  
and Mac (sort of) have a package management system, Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it  
probably wouldn’t be too hard for you to implement if it’s very important  
to you. I’m sure others would appreciate the contribution.

Matt Moretti  
​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris [Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)  
wrote:

> I disagree.
> 
> winodow\_package "could" have been written such that when the source is a  
> URL (http://), it would do a remote\_file first, and then execute the  
> local package, all underneath the covers. Then its behavior is in-line with  
> the package resource.
> 
> Chris
> 
> -----Original Message-----  
> From: Daniel DeLeo [[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)] On Behalf Of Daniel DeLeo  
> Sent: Wednesday, February 11, 2015 12:08 PM  
> To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> Subject: [chef] Re: RE: Re: Why is my windows\_package source attribute  
> getting mucked up?
> 
> On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:
> 
> > More (annoying) inconsistencies (in expectations) between Windows and  
> > Linux based nodes.
> > 
> > Chris
> 
> I agree there are a lot of areas where Windows functionality needs to  
> catch up, but this isn’t one of them. On Linux when you install a package  
> that doesn’t come from a centralized package repo, you have to use a  
> separate remote file to fetch it as well. The difference is that most Linux  
> distros come with a centralized package repo, which provides most of the  
> packages you want. The only way Chef could make windows behave similarly is  
> to force you to install Chocolatey when you install Chef. FWIW I had the  
> exact same experience on Solaris a few years back where the only  
> centralized package repos are (were?) 3rd party so you had to do a bit of  
> extra work to fetch everything.
> 
> --  
> Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Todd\_Pigram](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/todd_pigram/32/138_2.png) [@Todd\_Pigram](https://discourse.chef.io/u/Todd_Pigram)\
**Post date:** [February 12, 2015, 5:22pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/8 "2015-02-12T17:22:05Z")

</div>

windows\_package can use URLs. I use them everyday.

Attribute

default['tool']['url'] = "  
[Download 7z920-x64.msi (7-Zip)](http://downloads.sourceforge.net/sevenzip/7z920-x64.msi)"

Recipe

windows\_package "7-Zip 9.20 (x64 version)" do  
source node['tool']['url']  
action :install  
not\_if {::File.exists?(node['tool']['file'])}  
not\_if {reboot\_pending?}  
end

On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti [werebus@gmail.com](mailto:werebus@gmail.com) wrote:

> After looking around a little bit, I actually can’t see any evidence that  
> any of the \_package resources can take an http “source” with the  
> exception of “gem\_package”. The standard way to go about this if you can’t  
> use the OS’s built-in package manager is to retrieve the file with  
> remote\_file and then install it. You’re pretty-much just running up  
> against “Linux, BSD, and Mac (sort of) have a package management system,  
> Windows doesn’t”.
> 
> That being said, it does seem like a reasonable feature to have and it  
> probably wouldn’t be too hard for you to implement if it’s very important  
> to you. I’m sure others would appreciate the contribution.
> 
> Matt Moretti  
> ​
> 
> On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris [Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)  
> wrote:
> 
> > I disagree.
> > 
> > winodow\_package "could" have been written such that when the source is a  
> > URL (http://), it would do a remote\_file first, and then execute the  
> > local package, all underneath the covers. Then its behavior is in-line with  
> > the package resource.
> > 
> > Chris
> > 
> > -----Original Message-----  
> > From: Daniel DeLeo [[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)] On Behalf Of Daniel  
> > DeLeo  
> > Sent: Wednesday, February 11, 2015 12:08 PM  
> > To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> > Subject: [chef] Re: RE: Re: Why is my windows\_package source attribute  
> > getting mucked up?
> > 
> > On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:
> > 
> > > More (annoying) inconsistencies (in expectations) between Windows and  
> > > Linux based nodes.
> > > 
> > > Chris
> > 
> > I agree there are a lot of areas where Windows functionality needs to  
> > catch up, but this isn’t one of them. On Linux when you install a package  
> > that doesn’t come from a centralized package repo, you have to use a  
> > separate remote file to fetch it as well. The difference is that most Linux  
> > distros come with a centralized package repo, which provides most of the  
> > packages you want. The only way Chef could make windows behave similarly is  
> > to force you to install Chocolatey when you install Chef. FWIW I had the  
> > exact same experience on Solaris a few years back where the only  
> > centralized package repos are (were?) 3rd party so you had to do a bit of  
> > extra work to fetch everything.
> > 
> > --  
> > Daniel DeLeo

--

Todd Pigram

> **[Todd Pigram on about.me](https://about.me/ToddPigram)**
>
> I am a director and architect in United States. Visit my website.

[www.linkedin.com/in/toddpigram/](http://www.linkedin.com/in/toddpigram/)  
@pigram86 on twitter

> **[New community features for Google Chat and an update on Currents](https://workspaceupdates.googleblog.com/2023/04/new-community-features-for-google-chat-and-an-update-currents%20.html)**
>
> Note:  This blog post outlines upcoming changes to Google Currents for Workspace users. For information on the previous deprecation of Googl...

Mobile - 216-224-5769

---

<div class="post-metadata">

**Author:** ![Chris\_F](https://avatars.discourse-cdn.com/v4/letter/c/fbc32d/32.png) [@Chris\_F](https://discourse.chef.io/u/Chris_F)\
**Post date:** [February 12, 2015, 5:36pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/9 "2015-02-12T17:36:33Z")

</div>

I get the error reported here, and I have Windows Server 2012 R2

[http://lists.opscode.com/sympa/arc/chef/2014-05/msg00328.html](http://lists.opscode.com/sympa/arc/chef/2014-05/msg00328.html)

Chris

From: Todd Pigram [[mailto:todd@toddpigram.com](mailto:todd@toddpigram.com)]  
Sent: Thursday, February 12, 2015 12:22 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: Re: RE: Re: RE: Re: Why is my windows\_package source attribute getting mucked up?

windows\_package can use URLs. I use them everyday.

Attribute

default['tool']['url'] = "[Download 7z920-x64.msi (7-Zip)](http://downloads.sourceforge.net/sevenzip/7z920-x64.msi)"

Recipe

windows\_package "7-Zip 9.20 (x64 version)" do  
source node['tool']['url']  
action :install  
not\_if {::File.exists?(node['tool']['file'])}  
not\_if {reboot\_pending?}  
end

On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti \<[werebus@gmail.com](mailto:werebus@gmail.com)[mailto:werebus@gmail.com](mailto:werebus@gmail.com)\> wrote:

After looking around a little bit, I actually can’t see any evidence that any of the \_package resources can take an http “source” with the exception of “gem\_package”. The standard way to go about this if you can’t use the OS’s built-in package manager is to retrieve the file with remote\_file and then install it. You’re pretty-much just running up against “Linux, BSD, and Mac (sort of) have a package management system, Windows doesn’t”.

That being said, it does seem like a reasonable feature to have and it probably wouldn’t be too hard for you to implement if it’s very important to you. I’m sure others would appreciate the contribution.

Matt Moretti  
​

On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris \<[Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)[mailto:Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)\> wrote:  
I disagree.

winodow\_package "could" have been written such that when the source is a URL (http://), it would do a remote\_file first, and then execute the local package, all underneath the covers. Then its behavior is in-line with the package resource.

Chris

-----Original Message-----  
From: Daniel DeLeo [[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)] On Behalf Of Daniel DeLeo  
Sent: Wednesday, February 11, 2015 12:08 PM  
To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)[mailto:chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
Subject: [chef] Re: RE: Re: Why is my windows\_package source attribute getting mucked up?

On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:

> More (annoying) inconsistencies (in expectations) between Windows and Linux based nodes.
> 
> Chris

I agree there are a lot of areas where Windows functionality needs to catch up, but this isn’t one of them. On Linux when you install a package that doesn’t come from a centralized package repo, you have to use a separate remote file to fetch it as well. The difference is that most Linux distros come with a centralized package repo, which provides most of the packages you want. The only way Chef could make windows behave similarly is to force you to install Chocolatey when you install Chef. FWIW I had the exact same experience on Solaris a few years back where the only centralized package repos are (were?) 3rd party so you had to do a bit of extra work to fetch everything.

--  
Daniel DeLeo

--

Todd Pigram

> **[Todd Pigram on about.me](https://about.me/ToddPigram)**
>
> I am a director and architect in United States. Visit my website.

[www.linkedin.com/in/toddpigram/](http://www.linkedin.com/in/toddpigram/)[http://www.linkedin.com/in/toddpigram/](http://www.linkedin.com/in/toddpigram/)  
@pigram86 on twitter  
[Google Workspace Updates: New community features for Google Chat and an update on Currents](https://plus.google.com/+ToddPigram86)  
Mobile - 216-224-5769

---

<div class="post-metadata">

**Author:** ![Jay\_Mundrawala](https://avatars.discourse-cdn.com/v4/letter/j/ed8c4c/32.png) [@Jay\_Mundrawala](https://discourse.chef.io/u/Jay_Mundrawala)\
**Post date:** [February 12, 2015, 5:39pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/10 "2015-02-12T17:39:30Z")

</div>

The windows cookbook supports downloading from a url, the resource in core  
does not...yet

On Thu, Feb 12, 2015 at 11:36 AM, Fouts, Chris [Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)  
wrote:

> I get the error reported here, and I have Windows Server 2012 R2
> 
> [chef - [chef] Re: windows\_package source problems in windows 2008 and not in 2012](http://lists.opscode.com/sympa/arc/chef/2014-05/msg00328.html)
> 
> Chris
> 
> _From:_ Todd Pigram [[mailto:todd@toddpigram.com](mailto:todd@toddpigram.com)]  
> _Sent:_ Thursday, February 12, 2015 12:22 PM  
> _To:_ [chef@lists.opscode.com](mailto:chef@lists.opscode.com)  
> _Subject:_ [chef] Re: Re: RE: Re: RE: Re: Why is my windows\_package  
> source attribute getting mucked up?
> 
> windows\_package can use URLs. I use them everyday.
> 
> Attribute
> 
> default['tool']['url'] = "  
> [Download 7z920-x64.msi (7-Zip)](http://downloads.sourceforge.net/sevenzip/7z920-x64.msi)"
> 
> Recipe
> 
> windows\_package "7-Zip 9.20 (x64 version)" do
> 
> source node['tool']['url']
> 
> action :install
> 
> not\_if {::File.exists?(node['tool']['file'])}
> 
> not\_if {reboot\_pending?}
> 
> end
> 
> On Thu, Feb 12, 2015 at 11:42 AM, Matthew Moretti [werebus@gmail.com](mailto:werebus@gmail.com)  
> wrote:
> 
> After looking around a little bit, I actually can’t see any evidence that  
> any of the \_package resources can take an http “source” with the  
> exception of “gem\_package”. The standard way to go about this if you can’t  
> use the OS’s built-in package manager is to retrieve the file with  
> remote\_file and then install it. You’re pretty-much just running up  
> against “Linux, BSD, and Mac (sort of) have a package management system,  
> Windows doesn’t”.
> 
> That being said, it does seem like a reasonable feature to have and it  
> probably wouldn’t be too hard for you to implement if it’s very important  
> to you. I’m sure others would appreciate the contribution.
> 
> Matt Moretti
> 
> ​
> 
> On Thu, Feb 12, 2015 at 10:47 AM, Fouts, Chris [Chris.Fouts@sensus.com](mailto:Chris.Fouts@sensus.com)  
> wrote:
> 
> I disagree.
> 
> winodow\_package "could" have been written such that when the source is a  
> URL (http://), it would do a remote\_file first, and then execute the  
> local package, all underneath the covers. Then its behavior is in-line with  
> the package resource.
> 
> Chris
> 
> -----Original Message-----  
> From: Daniel DeLeo [[mailto:ddeleo@kallistec.com](mailto:ddeleo@kallistec.com)] On Behalf Of Daniel DeLeo  
> Sent: Wednesday, February 11, 2015 12:08 PM  
> To: [chef@lists.opscode.com](mailto:chef@lists.opscode.com)
> 
> Subject: [chef] Re: RE: Re: Why is my windows\_package source attribute  
> getting mucked up?
> 
> On Tuesday, February 10, 2015 at 2:46 PM, Fouts, Chris wrote:
> 
> > More (annoying) inconsistencies (in expectations) between Windows and  
> > Linux based nodes.
> > 
> > Chris
> 
> I agree there are a lot of areas where Windows functionality needs to  
> catch up, but this isn’t one of them. On Linux when you install a package  
> that doesn’t come from a centralized package repo, you have to use a  
> separate remote file to fetch it as well. The difference is that most Linux  
> distros come with a centralized package repo, which provides most of the  
> packages you want. The only way Chef could make windows behave similarly is  
> to force you to install Chocolatey when you install Chef. FWIW I had the  
> exact same experience on Solaris a few years back where the only  
> centralized package repos are (were?) 3rd party so you had to do a bit of  
> extra work to fetch everything.
> 
> --  
> Daniel DeLeo
> 
> --
> 
> Todd Pigram  
> [Todd Pigram - United States, Inversion6, RETS Electronic Institute, Saint Xavier High School - Louisville KY | about.me](http://about.me/ToddPigram)  
> [www.linkedin.com/in/toddpigram/](http://www.linkedin.com/in/toddpigram/)
> 
> @pigram86 on twitter  
> [Google Workspace Updates: New community features for Google Chat and an update on Currents](https://plus.google.com/+ToddPigram86)
> 
> Mobile - 216-224-5769

---

<div class="post-metadata">

**Author:** ![btm](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/btm/32/1089_2.png) [@btm](https://discourse.chef.io/u/btm)\
**Post date:** [February 12, 2015, 6:33pm UTC](https://discourse.chef.io/t/why-is-my-windows-package-source-attribute-getting-mucked-up/6264/11 "2015-02-12T18:33:56Z")

</div>

On Thu, Feb 12, 2015 at 12:39 PM, Jay Mundrawala [jdm@getchef.com](mailto:jdm@getchef.com) wrote:

> The windows cookbook supports downloading from a url, the resource in core  
> does not...yet

Right. I migrated the windows package provider from the windows  
cookbook into core Chef. The version is core does not support URLs in  
the source, the cookbook still does.

As Matthew and Dan noted, it's not common behavior for the other  
resources to take URLs because it means embedding (or worse,  
duplicating) another resource. There's one super hairy place that we  
do this, and it's the deploy resource -\> git/svn resource. Based on  
the principle of resources primitives each performing a single task  
(i.e. the Unix philosophy) I don't think we really designed resources  
to be used this way and it leads to a silly hack of adding all the  
attributes from the embedded resource (remote\_file) into the one  
you're using (windows\_package). We're in a better place now than a few  
years ago because we can more easily build provider specific resources  
(e.g. the windows\_package provider uses the windows\_package resource,  
not the package resource). But still, I wondered if we need to work  
through on RFC for a standard way of embeddeding resources and passing  
their attributes.

Bryan