We now know a little more about this duget thing, and have seen how to create a package. But a package cannot be consumed ‘in situ’ – it must be made available via a feed. Which brings us to the PUSH command.
NOTE: Don’t worry, I have my priorities straight. This post was written before Liev arrived. 🙂
The PUSH Command
To make a package available for consumption by other projects, it must be pushed to a feed. The feeds available are identified in a duget configuration file named duget.config. Actually, multiple duget.config files may be involved.
The first is the ‘global’ configuration, which is not strictly global but actually specific to the current user account. Here’s mine:
{
packagesFolder: "packages",
feeds: [
{ name: "alpha", folder: "\\\\nuc\\duget\\alpha" },
{ name: "release", folder: "\\\\nuc\\duget\\feed" },
{ name: "duget.org", url: "https://api.duget.org/v1/index.json" }
],
disabledFeeds: [“duget.org”]
}duget will load this configuration first and then look ’up’ the folder hierarchy from the working location, looking for additional duget.config files. If found these are then applied, furthest first. This allows “local” configuration changes to be based on the “inherited” configuration to that point. So for example I might introduce an additional feed to be used by projects in a certain folder, but projects in another folder won’t be aware of that additional feed (unless they are in a sub-folder).
There are other variations that can be accomplished with local configs which I won’t go into here. But if you’re familiar with nuget configuration, you will find this all very familiar. 😉
The packagesFolder property identifies a folder to act as the package cache.
The Package Cache
This is the first place that duget looks for packages when resolving dependencies. Obviously when duget encounters a dependency on a package for the first time (either a new package id or a new version of a known package) it will not be in the cache and so duget will attempt to fetch that package from one of the configured feeds. If successful, the package is stashed in the cache for future reference.
The feeds property then identifies the feeds that duget will use to try to find those packages that aren’t in the cache.
In the example above you can see that I have multiple feeds configured. The first two are the only two that are actually of any use currently. The duget.org http feed is non-functional – duget ignores (or rejects) all http feeds for now. In this case I have simply disabled the feed.
Local configuration files can enable/disable “inherited” feeds in the configuration as well as introducing new feeds.
The two file system feeds configured identify two folders that are shared by my build machine, each representing two feeds – an alpha feed or “pre-release channel” and a regular feed. A similar configuration exists on that build machine. So when a successful build produces an updated package, my dev machines can immediately consume both pre-release and release packages directly from the build machine.
I can of course also push new packages from my dev machine as well, as long as I have the necessary permissions to the file share in question (this is the extent of any security in duget currently).
Pushing a new or updated package is the same whether from a build machine and uses the push command. Again, to push all packages from the current folder to the default push feed you would simply:
duget push
With the configuration above this would fail since there is no default push feed configured and so one must be specified on the command line, e.g.:
duget push --feed:alpha
If there are multiple package files in the folder, specific packages may be selected for pushing by specifying those as arguments to the command (just the package id is needed):
duget push deltics.smoketest --feed:alpha
By default the package file will delete any pushed packages from the original folder. This can be prevented by adding a <strong>--noDelete</strong> switch.
Thus far we’ve seen how duget can be used to create packages and make them available for use via one or more feeds. Tomorrow we’ll look at how projects consume packages from those feeds with the restore and update commands.