NIPM feed-download command options

[jfolerka]

It would be great if the feed-download command would accept parameters for:

• Downloading a feed that's not in the current configuration (feed is in a directory)
• Including dependencies in the download
• Including EULAs in the download
• Including recommended packages in the download
• Including suggested packages in the download

[Scott_Richardson]

Declining this idea.

Below are the 4 sub-asks, with rationale for why the idea is being declined:

1. Downloading a feed that's not in the current configuration (feed is in a directory)
   • The proper way to implement this is to use the following commands using a custom config file:
     nipkg.exe feed-add --config=C:\temp\nipkg.ini --name=temp https://<path>
     nipkg.exe update --config=C:\temp\nipkg.ini
     nipkg.exe feed-download --config=C:\temp\nipkg.ini "temp" “c:\temp\myfeed”
2. Including dependencies in the download
   • In general, the creator of feeds should include all dependencies, so an option for this in that case would not be required.
   • If dependencies are not included and are in different feeds, then the nipkg.exe download command should be used instead and use the --all-deps option.
3. Including EULAs in the download
   • If EULAs files are included in the feed directory and in the Packages feed file, they will be downloaded.
   • If EULAs are not included and are in different feeds, then the nipkg.exe download command should be used instead.
4. Including recommended/suggested packages in the download
   • If the feed you are downloading already has recommended and suggested packages, they will be downloaded with feed-download.
   • In order to discover recommended and suggested, a top-level package(s) must be specified to then search for what is recommended/suggested. The feed-download command does not specify top-level packages.

[jfolerka]

Hi Scott,

I appreciate the response, please consider that the goal of my idea is not "if" the task can be done nor "how" it can be currently achieved. I have, in fact, achieved my desired results, but it required quite a bit of scripting and understanding of the nuts and bolts of NIPM, which is a great tool, and I think it could be more flexible.

My idea is centered around ease-of-use and quality-of-life improvements for NIPM.

Consider the following use-case:

I have a collection of custom packages that have dependencies on each other and also on NI packages. In my case I have indeed placed all of these packages, including EULAs in the same folder. The packages in this folder can then be revision-controlled.

I did not however (and would not) think of placing every single NI dependency/recommend/suggest in that revision-controlled folder. However, I would like to download these packages and their NI dependencies/recommends/suggests into another directory easily and reliably so I can pack them all into an installer.

As I understand the workings of NIPM, if I use a dummy config file, then most feeds will be unavailable, this is not desired.

If feed-download provided some of the flexibility from my idea, there wouldn't be a need to invoke nipkg multiple times or mess with temporary configuration files (I'm basically asking for a bit of automation sugar) or each user having to write their own scripts for this task.

Consider turning the three invocations of nipkg to download the feed plus many others to download dependencies into a single one:

nipkg.exe feed-download --path="%someLocalFolder%" --deps --eulas --suggests --recommends "%destinationFoler%"

• --path tells NIPM to look for the feed in the specified local folder (automate temporarily adding this feed to config. and attempting to download)
• --deps --eulas --suggests --recommends tell NIPM to also download these items for all of the packages in the feed (currently my scripts poke into the package data, collect the dependencies, determine if they are mine or NI's, eliminate duplicates, and perform a download command for each). NIPM could do this much more efficiently I think, since with a single invocation of the feed-download command it would have visibility into all of the packages in the feed, plus any in the current configuration and determine where to get each package to satisfy the dependencies. The feed would be examined first, if a dependency is not found, then try to find it in the current configuration, if not found then error. Fair: --deps and --eulas can just be --deps and all four options could be --all-deps

[Scott_Richardson]

Understood. Using --suggests and --recommends on a feed is too broad and I feel that those options should target a specific list of packages to target. If anything I think that adding --suggests and --recommends options to nipkg.exe download would be of general value.