Conditional sources?

When developing a set of components, (e.g… Vagabond --> MBrace.Core --> MBrace.Azure -> …), each with their own package, it would be very convenient to be able refer to a “ephemeral” package feed such as an AppVeyor feed in order to access alpha versions of the packages without publishing them to nuget.org

Of course I can add

source https://ci.appveyor.com/nuget/vagabond-6odcsr0usg1g

but the problem is that I would only want this to be active on my own local machine, or on the appveyor build, but never when building “final” non-alpha versions of packages that get pushed to nuget.

Basically I’m wondering if it could be plausible to have a feature where source declarations are conditional in some way. It’s not entirely obvious to me whet they would be conditional on - perhaps in this case I would just want a “not golden” or “devmode” flag or something. And it’s no clear how it would be applied, since all the paket.lock etc. is dependenct on this feed, so you have to re-run paket.exe

This is really just thinking out loud but it seems a common situation, and I’m wondering if people have hit this before? I really fear pushing broken sets of packages to nuget.org that accidentally depend on alpha versions of other packages that aren’t available on nuget.org

thanks don

[dsyme]

I’ll close this. I think the problem is very real and fundamental in the long run - in the long run we have to have mechanisms/practices in place where we can push a change to a base package through a whole graph of other packages relatively easily, all on a local machine, with no expansion of the DAG and with full paket dependency management and consistency checking.

But I don’t have any specific mechanism to propose just yet - I’ll keep thinking it over.

[theimowski]

This kind of “cascade” behavior IMO would make things very complicated, and that’s what we tried to avoid when introducing paket.local

I think there’s one important detail that might not seem obvious at first: Even if you have this kind of dependency chain, you can still test locally changes made in A component from D component without rebuilding components between. In practice this means:

• apply change in A
• manually trigger the build of A
• make sure there’s an override for A in D
• restore packages (with override) and build D
• run D with the changes applied in A

And it seems this workflow could be easy enough given one is using floating version dependencies with default Paket resolution strategy, which is take the highest version matching.