Support for multiple package sources

Sep 9, 2010 at 2:30 AM
Edited Sep 9, 2010 at 2:43 AM

I was thinking about this in the car home. The title isn't great here but this is the use case.

  1. Create a local repository (c:\packages) and another (d:\packages).
  2. Put package1 in c:\packages
  3. Put package2 in d:\packages
  4. Create a new project
  5. Change-PackageSource c:\packages
  6. Add-Package package1
  7. Change-PackageSource d:\packages
  8. Add-Package package2
  9. Zip up solution/check into source control/etc.
  10. Give to another developer who has same pacakge sources available (these could be URIs or whatever, doesn't matter)
  11. Give an updated package2 to developer
  12. Ask developer to update his solution

Problem:

The package itself doesn't know where it came from. The developer needs to be pointing to the same repository that the original developer used when he created the solution.

For the developer to actually get the right updates he has to do Change-PackageSource, update, change, update and hope he's got all the packagesources that are in his project.

I see this as a huge problem. If I'm a developer on a project, I shouldn't have to know where the original packages came from nor should I have my environment setup that way. What if I prefer to pull my packages from packages.codeplex.com or bilspackagewarehouse.com.

There's also the issue of versioning. Let's say the project was built with package2 v2 but the repository I normally pull from only has package2 v1. I'll never get the latest version if the maintainers of my package source are lazy bums who don't update their package repository.

Gem has a similar problem to this and relies on the packages to be sourced from any number of repositories. You can set an env var with the list of them, issue a gem source cmd (or something like that, can't remember the exact syntax) or override the package source when you install/update a gem (gem update mygem --source=http://somerepository). Still requires the dev to have intimate knowledge of where to get the right package from the right place.

IMHO a dev shouldn't have to know where it came from and if it came from Bob's House of NuPack Packages, then that's where the updates should originate from by default (but let the dev override it if he feels that Jill's House of NuPack Packages is better.

Or am I making a big deal out of nothing here?

Sep 9, 2010 at 3:51 AM

I think this is a valid concern.  Can the package.xml in the project store the source uri ?

Sep 9, 2010 at 3:53 AM

I think it should. I look at subversion as an example. In the entries file is where the repository is. I can pull down anyones code and always get an update from the right place. I think the package source needs to be somewhere available to the system in order to retrieve it again. I think it might be a big deal because we have no files in the expanded package for this.

Developer
Sep 9, 2010 at 4:01 AM

So in summary, what does the workflow look like?

Sep 9, 2010 at 4:54 AM
Edited Sep 9, 2010 at 4:56 AM

I need to noodle it longer but basically there needs to be a new artifact or way to get meta-data into the solution that points back to the original source for the feed for that package. This is to allow anyone to grab a source tree and regardless of where their package source is configured as, be able to pull down the intended update for any given package. This needs to be done on a package by package basis, not a solution wide setting.

I think this is related to but not the same as [workitem:5]

Sep 9, 2010 at 7:53 AM

Yes, I think it makes sense.  It's more of a 'feed hint' for a given downloaded package.  i.e. it's not forced to get updates from there, but it's one location to try.

Sep 9, 2010 at 1:28 PM
erichexter wrote:

I think this is a valid concern.  Can the package.xml in the project store the source uri ?

 I forgot about the package.xml being there. Yeah, it could store the uri for the package(s) in the solution. Could just be an additional attribute on the package node now so from this:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="log4net" version="1.2.1" />
  <package id="NLog" version="1.0" />
  <package id="Castle.Core" version="1.2.0" />
  <package id="Castle.Ioc" version="2.1.1" />
  <package id="Moq" version="3.1.416.3" />
  <package id="OpenSearchToolkit" version="1.1" />
</packages>
</pre>

to this:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="log4net" version="1.2.1" source="http://myinternalpackageserver"/>
  <package id="NLog" version="1.0" source="c:\packages" />
  <package id="Castle.Core" version="1.2.0" source="https://packages.microsoft.com" />
  <package id="Castle.Ioc" version="2.1.1" source="https://packages.microsoft.com" />
  <package id="Moq" version="3.1.416.3" source="\\myserver\myshare\mypackages" />
  <package id="OpenSearchToolkit" version="1.1" source="select * from packages" />
</packages>
</pre>

Just kidding on the last one.

Kind of.

Coordinator
Sep 9, 2010 at 6:03 PM
Probably time to log a bug for this one. :)

Sep 9, 2010 at 6:07 PM

Done!

http://nupack.codeplex.com/workitem/20

Sep 9, 2010 at 6:13 PM

Is this package.xml file a new concept?

Sep 9, 2010 at 6:14 PM

packages.xml is added to the solution whenever a package is added (at least it is in my build but I might not be running latest). Has this been removed?

Sep 9, 2010 at 10:11 PM

It's still there.  Note that it gets added at the root of each project, and not at solution level.  This may make it a non ideal choice to store the feed source.  However, we can come up with something at solution level.

Coordinator
Jan 25, 2011 at 7:15 AM

Hey all. I'm reviving this thread because I wanted to talk about another potential workflow. I was meeting with an internal team using NuGet with an internal feed. They pointed out that when a new developer starts to work on their solution, the new developer has to remember to add their internal feeds to their list of package sources.

They would like to see a solution where when NuGet launches, it can scan packages.config and look for package sources that are not already in the current user's list of package sources. If any such package sources are found, NuGet could prompt the user asking the user to add the package source. What do you think of this idea?

It seems to me it could be useful for companies doing development with internal feeds.

Jan 26, 2011 at 1:26 PM
That would be helpful. What's the scenario for the disconnected worker? Just fails like normal when it can't resolve the url? I'm good with that as well. Just want to explore it out some more.
Jan 26, 2011 at 1:38 PM

That would solve a huge problem I have for our internal use of nuget at Dell. We have a lot of people working on dell.com and getting the inital source configured is the only part of our infrastructure we have not automated. I could hack the settings in with powershell but an officially supported process would be great.

sent from my mobile

On Jan 25, 2011 1:15 AM, "haacked" <notifications@codeplex.com> wrote:
> From: haacked
>
> Hey all. I'm reviving this thread because I wanted to talk about another potential workflow. I was meeting with an internal team using NuGet with an internal feed. They pointed out that when a new developer starts to work on their solution, the new developer has to remember to add their internal feeds to their list of package sources.They would like to see a solution where when NuGet launches, it can scan packages.config and look for package sources that are not already in the current user's list of package sources. If any such package sources are found, NuGet could prompt the user asking the user to add the package source. What do you think of this idea?It seems to me it could be useful for companies doing development with internal feeds.
>
>