Proposal: Dependencies outside of current repository

Oct 6, 2010 at 7:46 PM

When you have a private package repository set as default, what happens to dependencies that your private packages have?

Many people will likely have a few packages of their own that are of no use to the general public.

I suggest that a 'source' attribute be added to the dependency element as a means to point out where to retrieve a dependency package. 

The contents of this attribute could benefit from being formalized to indicate the kind of repos we are contacting, 

in the same way that Subversion has 'http://', 'svn://'. Leaving source out or empty would obviously mean current repository. 

<dependency id="somepublicpackage" minversion="" source="">

What do you guys think? 

Oct 6, 2010 at 8:01 PM
I like the way you think. Or perhaps you could publish a dependency and the package manager could check all of the feeds in priority order until it finds it.
More about auto discovery. What you propose is just a little different than this. More of a use this one, even if you haven't added this as a feed.
"Be passionate in all you do"

Oct 6, 2010 at 8:16 PM
Edited Oct 6, 2010 at 8:17 PM

I was going to start a discussion on auto discovery by priority. That should definately be in place, but adding that does not rule out this.

This can be viewed as an override to auto discovery. Specifying a dependency source allows any machine to require less setup to be able to manage dependencies.

Also, nitpicky developers (like me) will want to specify precisely which package should be installed, and not leave that to individual priority orderings.


More thoughts on this issue? 

Oct 6, 2010 at 8:25 PM
Edited Oct 6, 2010 at 8:29 PM

We already logged an issue with on this. I'll have to dig it up to see if it's the same feature you're looking for.

Here's the issue we created for this. Let us know if this is what you were thinking:

Oct 6, 2010 at 8:49 PM

Nice work!

That workitem describes how to have different repositorys at package level without having to configure/switch repos on your machine in order to update the packages, like this:

MyProject references:

Elmah sourced from

HelperUtils sourced from \\privaterepo. 

A necessity indeed! 


What I am attempting to propose a solution for is when a package itself has a dependency, in the example above, for when HelperUtils has a dependency that is sourced from

Without the ability to 'source' your dependencies when you author a package, Anyone who manages a repo has to pull in the whole dependency tree into his/her repo!

When I'm authoring a package I want to specify exactly where my dependencies come from.

This is a different issue (repo-side) from workitem #20 (client side)..

Oct 6, 2010 at 10:32 PM

I think I understand. Currently, you can only specify dependencies by ID.

      <dependency id="another-package" version="3.0.0" />
      <dependency id="yet-another-package" minversion="2.1.0" />

Perhaps we need a default source. The idea would be that we would look for the dependency there first, and then look in the current feed if for some reason the package isn't in the default source. Is that what you're asking for?

      <dependency id="another-package" version="3.0.0" defaultSource="" />
      <dependency id="yet-another-package" minversion="2.1.0" defaultSource="" />
It sounds reasonable. Could you log an issue for it? You can do so by clicking the "Copy to Work Item" link next to this and adding your own comments.


Oct 7, 2010 at 6:14 AM

We're getting somwhere! 

I've been poking around the source, and this would make for a pretty big changeset. It might be beneficial to fix #20 at the same time, as a lot of the same code is involved. 

In fact, one could argue that id and source should never be passed around the code one without the other, and that they should be merged into a new type, to avoid passing the wrong strings. 

Source should have the characteristic that no matter where in the code base, you can get a reference to a repository using just a source, nothing else. 

I'll log an issue as soon as we're more clear about what should go in it. :)


Oct 7, 2010 at 7:00 AM

I'll log a bug with what we have now. We can iterate on the design in the bug. Otherwise we'll lose track of it.

Oct 7, 2010 at 7:01 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Oct 7, 2010 at 7:02 AM

Created Issue