This is occurring because Chocolatey is trying to handle this itself
and always sets the source parameter on every call to NuGet. If the
Chocolatey script simply did not set the source (unless explicity
used) then NuGet would use its configured sources. I have verified
that this approach works by simply hacking out the source handling
call in my local Chocolatey.ps1 script.

Chocolatey seems to be handling the sources this way only so that it
can inject its own gallery URL as a source. If it were to add the
Chocolatey source directly to the NuGet.config file instead, then all
that extra handling would not be needed.

This approach could also address the multiple sources issue:
https://github.com/chocolatey/chocolatey/issues/82

Does this approach seem feasible? Are there any use cases that may be
adversely affected by this?

I will trying this out in a fork here: https://github.com/LucidSage/chocolatey

This seems like a good approach, at least on the surface. And the inserting
of chocolatey's source into nuget's config is certainly doable.

On of my big questions/concerns I have comes to the discrepancy of
priorities between the two tools, nuget versus chocolatey. Which source do
I want to have the most priority when I use NuGet in Visual Studio? Which
would I want to have the highest priority when I use Chocolatey?

The reason I ask this question is that the package name (the id) is not a
globally unique setting. If I have a package on one feed named the same as
a package on another feed, they don't even have to be the same thing. The
feed with the highest priority wins and you may not get what you want. This
will become more possible the more feeds you have in that configuration.

I'm certainly not trying to defeat the purpose of the idea, just trying to
understand a use case for both tools and how interactions may have
different priorities.
____
Rob
"Be passionate in all you do"

http://devlicio.us/blogs/rob_reynolds
http://ferventcoder.com
http://twitter.com/ferventcoder

You bring up a good point. Priorities between NuGet and Chocolatey could be
different. By default newly added sources are appended to the end, which
gives them the lowest priority. This can be changed by the user manually or
through VS if they wish, but as you point out this would not work well if
the priorities need to differ on a per tool basis.

On the other hand, this approach would not eliminate the ability to supply
the source argument if it is needed. So would this edge case be covered by
explicitly using the sources argument? An added alias for the chocolatey
source could also be added, like the webpi and gem aliases, that would make
this a little easier too.

Another tweak that may help is if the chocolatey entry in the NuGet.config
file is moved to be the highest priority by the chocolatey installer. I'm
just not sure which way would reduce the chances of conflict, so I'm not
sure if this is a good idea or not.

Those changes would cover the competing priorities case, which would
probably require specifying a source no matter which approach you use. The
advantage is that the happy path becomes easier.

Would there be any difficulties in having a separate
~/AppData/Chocolatey/Chocolatey.config file? It seems to me like mixing
NuGet and Chocolatey feeds would lead to confusion and rarely provide any
major advantages.

That could be done too, it would just require extra code. My original
proposal only requires to removal of some code in Chocolatey, which
simplifies it and just lets NuGet do what it does.

I guess it boils down to how often are they going to conflict? If would
happen often then having a separate config file would be worth the effort.
If not then going the simpler route seems to make more sense. That's a hard
question to answer.

Of course the simple approach could be implemented quickly and released for
feedback. Then if users start running into this problem, the separate
config file could be implemented then. That way little effort is required
and we will gain insight into the need for the more complex solution.