Type: New Feature
Affects Version/s: None
Fix Version/s: None
This pull request:
raised a few questions / issues about the best way to handle provider-specific parameters for package providers. We'd prefer not to be forced to stuff them into existing (somewhat unrelated) parameters and regex them out (though this does happen in certain providers), but we also want to be careful about adding too many provider-specific parameters to the main "package" resource type, which would clutter up the model and make it confusing.
The pip case is particularly interesting, because the two parameters that we need to add support for touch on a few conceptual things that we don't yet have parameters for:
1) The ability to specify multiple source destinations (we currently only have the "source" parameter, and the docs for it definitely read as though it is a single file/URL).
2) The ability to disable the default (implicit) source of a given package provider (this is what the "--index-url" option for pip does).
We should give some consideration to a long-term / general way to handle those two concepts; I'll create and link in a second ticket for that.
However, in the short term, we do have an existing parameter called "install_options" which would probably be a cleaner way to implement this (as opposed to overloading the "source" parameter).
In it's current incarnation, "install_options" is only used by the windows MSI provider. It's value is a hash, and the key/value pairs of the hash are treated as literal command line argument names / values. This should be sufficient for implementing the missing pip functionality.
Looping in Nick F. because the docs for this parameter (in master) are very windows-specific, and if this approach is adopted for the pip provider then we may need to tweak the docs.
Also, I think that we might want to consider a couple of possible changes to the definition of / usage of this parameter (it seems like it's a pretty new parameter, so hopefully we might be able to get away with changing it a bit as long as we retain backwards compatibility):
1) Consider renaming it to "provider_options"? This would just be a semantic change, but to me it makes it a bit more clear that what you are passing in are things that are specific to the provider in question, and not necessarily restricted to the install operation.
2) Consider changing the docs / intention so that, rather than treating this as a rigid list of command line name/value pairs (we currently seem to imply that they will just be dumped into the command line args, literally, without any validation or interpretation) that we treat it as a list of inputs to the specific provider, and allow the provider implementation to decide what to do with them. Some providers (e.g. MSI) may choose to simply dump them literally to the command line arguments, but other providers may use them in other ways.
So... comments would be appreciated on any or all of the above. I think that for the short term, the proposal is simply "refactor the existing pip pull request to use the 'install_options' parameter for passing in --extra-index-url and --index-url", and update the documentation accordingly. If any other action items come up via discussion I'll create new tickets for them.