{"id":2983,"date":"2019-09-25T19:10:13","date_gmt":"2019-09-25T07:10:13","guid":{"rendered":"https:\/\/www.deltics.co.nz\/blog\/?p=2983"},"modified":"2019-09-25T19:10:21","modified_gmt":"2019-09-25T07:10:21","slug":"duget-push-ing-packages","status":"publish","type":"post","link":"https:\/\/www.deltics.co.nz\/blog\/posts\/2983\/","title":{"rendered":"Duget – PUSH-ing Packages"},"content":{"rendered":"[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span>\n

We now know a little more about this <\/a>duget<\/a><\/strong> thing, and have seen how to create a package<\/a>. But a package cannot be consumed ‘in situ’ – it must be made available via a feed. Which brings us to the PUSH<\/strong> command.

NOTE: <\/em><\/strong>Don\u2019t worry, I have my priorities straight. This post was written before Liev arrived<\/a>. \ud83d\ude42<\/em><\/p>\n\n\n\n\n\n\n\n

The PUSH Command<\/h2>\n\n\n\n

To make a package available for consumption by other projects, it must be push<\/strong>ed to a feed. The feeds available are identified in a duget<\/strong> configuration file named duget.config<\/strong>. Actually, multiple<\/em> duget.config<\/strong> files may be involved.<\/p>\n\n\n\n

The first is the ‘global’ configuration, which is not strictly global but actually specific to the current user account. Here’s mine:<\/p>\n\n\n\n

{\n    packagesFolder: "packages",\n    feeds: [\n        { name: "alpha", folder: "\\\\\\\\nuc\\\\duget\\\\alpha" },\n        { name: "release", folder: "\\\\\\\\nuc\\\\duget\\\\feed" },\n        { name: "duget.org", url: "https:\/\/api.duget.org\/v1\/index.json" }\n    ],\n    disabledFeeds: [\u201cduget.org\u201d]\n}<\/code><\/pre>\n\n\n\n
duget<\/strong> will load this configuration first and then look \u2019up\u2019 the folder hierarchy from the working location, looking for additional duget.config<\/strong> 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<\/strong> to be used by projects in a certain folder, but projects in another<\/em> folder won’t be aware of that additional feed (unless they are in a sub-folder).<\/p>\n\n\n\n
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<\/strong> configuration, you will find this all very familiar.  \ud83d\ude09<\/p>\n\n\n\n
The packagesFolder<\/strong> property identifies a folder to act as the package cache.<\/p>\n\n\n\n
The Package Cache<\/h3>\n\n\n\n
This is the first place that duget<\/strong> looks for packages when resolving dependencies.  Obviously when duget<\/strong> encounters a dependency on a package for the first time (either a new package id<\/strong> or a new version of a known package) it will not be in the cache and so duget<\/strong> will attempt to fetch that package from one of the configured feeds.  If successful, the package is stashed in the cache for future reference.<\/p>\n\n\n\n
The feeds<\/strong> property then identifies the feeds that duget<\/strong> will use to try to find those packages that aren’t in the cache.<\/p>\n\n\n\n
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<\/strong> http feed is non-functional – duget<\/strong> ignores (or rejects) all http<\/em> feeds for now.  In this case I have simply disabled the feed.<\/p>\n\n\n\n
Local configuration files can enable\/disable \u201cinherited\u201d feeds in the configuration as well as introducing new feeds.<\/p>\n\n\n\n
The two file system feeds configured identify two folders that are shared by my build machine, each representing two feeds – an alpha feed or \u201cpre-release channel\u201d 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.<\/p>\n\n\n\n
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<\/strong> currently).<\/p>\n\n\n\n
\n\n\n\n
Pushing a new or updated package is the same whether from a build machine and uses the push<\/strong> command.  Again, to push all<\/em> packages from the current folder to the default push feed you would simply:<\/p>\n\n\n\n
duget push<\/code><\/p>\n\n\n\n
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.:<\/p>\n\n\n\n
duget push --feed:alpha<\/code><\/p>\n\n\n\n
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):<\/p>\n\n\n\n
duget push deltics.smoketest --feed:alpha<\/code><\/p>\n\n\n\n
By default the package file will delete any pushed packages from the original folder.  This can be prevented by adding a <strong>--noDelete<\/strong><\/code> switch.<\/p>\n\n\n\n
\n\n\n\n
Thus far we’ve seen how duget<\/strong> 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<\/strong> and update<\/strong> commands.<\/p>\n","protected":false},"excerpt":{"rendered":"
[Estimated Reading Time: <\/span> 3<\/span> minutes]<\/span><\/span> 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\u2019t worry, I have my priorities straight. This post was written before […]<\/p>\n","protected":false},"author":2,"featured_media":2981,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"jetpack_publicize_message":"Duget - how to publish packages to make them available for consumption in projects.","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[324,323,4,321,346],"tags":[292,344,345],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1","jetpack_shortlink":"https:\/\/wp.me\/p1TKYv-M7","jetpack_sharing_enabled":true,"jetpack-related-posts":[{"id":2985,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2985\/","url_meta":{"origin":2983,"position":0},"title":"Duget – RESTORE, UPDATE and What’s Next ?","date":"26 Sep 2019","format":false,"excerpt":"Wrapping up this short series on duget, discussing RESTORE and UPDATE, arguably most important and useful commands in the duget repertoire.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2979,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2979\/","url_meta":{"origin":2983,"position":1},"title":"Duget Package Manager for Delphi","date":"24 Sep 2019","format":false,"excerpt":"An overview of the the duget package manager, outlining the current state of this project and the first in a quick-fire series to explore the key features.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/duget-warriors.png?fit=929%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":3000,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/3000\/","url_meta":{"origin":2983,"position":2},"title":"VersionInfo and Semantic Versioning","date":"08 Oct 2019","format":false,"excerpt":"How to make Semantic Version make sense in a VERSIONINFO world without Semantic Versioning.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/bart-simpson-generator-1.png?fit=1024%2C343&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2936,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2936\/","url_meta":{"origin":2983,"position":3},"title":"Azure DevOps – Iterative Insertion Fixed!","date":"19 Sep 2019","format":false,"excerpt":"I figured out the iterative insertion problem and my build pipeline is now TIGHT! Fixing it was super-easy in fact, barely an inconvenience.","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/pipelines-hero-code-1024x256.jpg?fit=1024%2C256&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2919,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2919\/","url_meta":{"origin":2983,"position":4},"title":"Azure DevOps – Now You Too Can Use My Template(s)","date":"14 Sep 2019","format":false,"excerpt":"Learn how you too can use my Delphi build template in your own Azure DevOps pipelines, and a sneak preview of something special coming soon...","rel":"","context":"In "automation"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/github-512.png?fit=512%2C512&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]},{"id":2931,"url":"https:\/\/www.deltics.co.nz\/blog\/posts\/2931\/","url_meta":{"origin":2983,"position":5},"title":"‘Sorry, this script is too long…’","date":"18 Sep 2019","format":false,"excerpt":"An object lesson on the importance of defensive programming and providing helpful error messages to your users.","rel":"","context":"In "Azure DevOps"","img":{"alt_text":"","src":"https:\/\/i0.wp.com\/www.deltics.co.nz\/blog\/wp-content\/uploads\/Mark_Twain_life_1900s.jpg?fit=883%2C331&ssl=1&resize=350%2C200","width":350,"height":200},"classes":[]}],"_links":{"self":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2983"}],"collection":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/comments?post=2983"}],"version-history":[{"count":4,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2983\/revisions"}],"predecessor-version":[{"id":2996,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/posts\/2983\/revisions\/2996"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media\/2981"}],"wp:attachment":[{"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/media?parent=2983"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/categories?post=2983"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.deltics.co.nz\/blog\/wp-json\/wp\/v2\/tags?post=2983"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}