These are chat archives for chocolatey/chocolatey-oneget

1st
Mar 2015
Joel Bennett
@Jaykul
Mar 01 2015 04:27
Yeah, I think I'll send you some pull requests on several of these to let me access objects, because objects are what OneGet wants
Joel Bennett
@Jaykul
Mar 01 2015 06:42
I don't know ... your Run() method can't return anything. How would you prefer to actually expose returned results?
Joel Bennett
@Jaykul
Mar 01 2015 06:51
Also, in each command you have a configure_argument_parser which seem like the only way for me to get a list of the parameters that command understands ...
Is it safe to assume that if I wanted the "name" of these options, I have to actually split the first word off the option description rather than trying to parse the key (since they key seems to be in no particular order)?
Site note: if I were doing this, I would have overloaded the PowerShell Cmdlet method of listing parameters (actual properties on the object with a ParameterAttribute).
Joel Bennett
@Jaykul
Mar 01 2015 18:20
@ferventcoder why is the ChocolateyConfiguration passed into the members of IChocolateyConfigSettingsService ?
It looks like the expectation is that those methods would calculate from the configuration that's passed in?
Rob Reynolds
@ferventcoder
Mar 01 2015 18:56
You are trying to gather the params for each command automatically. I see. Perhaps we need a central place for that. For now we don't have a good way of gathering that
At least in an automated fashion
@Jaykul you may need to be more clear e.g
Links
Joel Bennett
@Jaykul
Mar 01 2015 19:03
Yeah
As you know, I'm just trying to meet the demands of OneGet ;-)
Rob Reynolds
@ferventcoder
Mar 01 2015 19:04
:)
Joel Bennett
@Jaykul
Mar 01 2015 19:05
Obviously we don't have to implement everything
But it seems to me that the minimum is FindPackage and InstallPackage
And it sort-of makes sense to me that we need to support Sources too
So I figured the easiest thing to start with would be Sources
My first stop is the command I listed a while ago:
Lets.GetChocolatey().Set(conf => { conf.CommandName = "Source"; conf.SourceCommand.Command = SourceCommandType.list; }).Run();
But obviously (as you mentioned) Run doesn't return anything, it's async fire and forget
Whereas in OneGet's ResolvePackageSources I need to call request.YieldPackageSource(name, location, ....)
Joel Bennett
@Jaykul
Mar 01 2015 19:11
So I looked in ChocolateySourceCommand.run, and it's calling methods from the interface above such as _configSettingsService.source_list(configuration);
But: 1) the ConfigSettingsService doesn't return things either, it writes them out
And 2) the configuration parameter isn't ever being used in any of these methods
So I am looking at adding an overload for source_list where it takes a lamda to do what it's doing now ....
But:
1) Why should I pass a configuration that's being ignored?
2) Should I expose both in the interface?
....
As for the other, I do need to decide which parameters to expose, but OneGet has a GetDynamicOptions parameter ... so I was thinking about just exposing "all" the options that OneGet doesn't expose. They want: name, expectedType, isRequired ... and an optional enum of valid values
Rob Reynolds
@ferventcoder
Mar 01 2015 19:16
Look at nugetservice.list_run
Joel Bennett
@Jaykul
Mar 01 2015 19:18
Looking
Rob Reynolds
@ferventcoder
Mar 01 2015 19:18
It has a similar construct to returning objects and not just logging. I think that is where you may want to go. As far as unused configuration param - it may be there as a holdover and no longer required
Joel Bennett
@Jaykul
Mar 01 2015 19:19
Should I add something like that to other commands?
Rob Reynolds
@ferventcoder
Mar 01 2015 19:19
Let's start with source list.
Joel Bennett
@Jaykul
Mar 01 2015 19:20
Yeah
Rob Reynolds
@ferventcoder
Mar 01 2015 19:20
That way we can adjust from one before you do a ton of work
Joel Bennett
@Jaykul
Mar 01 2015 19:20
FYI: I am only concerned about the configuration parameter because it looks like I have a way to create a configuration, but when I call those methods you're ignoring the configuration I created and using the configuration on disk instead -- that's potentially really confusing.
Yeah
So
The problem with the Source command is that it doesn't do anything itself
Except provide parameters
It just calls the ChocolateyConfigSettingsService
Rob Reynolds
@ferventcoder
Mar 01 2015 19:21
Thats all those command classes do
Joel Bennett
@Jaykul
Mar 01 2015 19:21
which is based on the interfaces, etc.
Rob Reynolds
@ferventcoder
Mar 01 2015 19:21
They setup and validate params
And know what to call next
Joel Bennett
@Jaykul
Mar 01 2015 19:22
So what I was looking at is this:
    public void source_list(ChocolateyConfiguration configuration)
    {
        foreach (var source in configFileSettings.Sources)
        {
            this.Log().Info(() => "{0}{1} - {2}".format_with(source.Id, source.Disabled ? " [Disabled]" : string.Empty, source.Value));
        }
    }
and I figured that I could make the center line of that a lambda that's passed in
alternatively, I can just make an enumerable overload
Rob Reynolds
@ferventcoder
Mar 01 2015 19:22
I could see an IList<SourceSomethingType> being returned
Joel Bennett
@Jaykul
Mar 01 2015 19:24
really all I need is a property that exposes configFileSettings.Sources.AsQueryable() (or something else readonly)
Since we're just ignoring the configuration anyway
I mean, ignoring the parameter
Rob Reynolds
@ferventcoder
Mar 01 2015 19:27
It would need to be mapped to something else
Joel Bennett
@Jaykul
Mar 01 2015 19:28
what do you mean?
Rob Reynolds
@ferventcoder
Mar 01 2015 19:28
No direct access to the config file settings
Joel Bennett
@Jaykul
Mar 01 2015 19:28
right, that's why I said .AsQueryable
but it could be .ToArray()
I can add:
    public IList<ConfigFileSourceSetting> source_list()
    {
        return configFileSettings.Sources.ToArray();
    }
If that's ok with you (for now), it gets us up to the next level ...
The next problem is that in ChocolateySourceCommand uses only the interface, so I need to expose that method in IChocolateyConfigSettingsService
I can add it ...
But looking at it in the interface, it looks like (for consistency) the method should be:
    public IList<ConfigFileSourceSetting> source_list(ChocolateyConfiguration configuration)
    {
        return configFileSettings.Sources.ToArray();
    }
Joel Bennett
@Jaykul
Mar 01 2015 19:34
Obviously I can't add that to the interface, because it has the same name as the other method
or rather, because the signature matches except for the return type
Rob Reynolds
@ferventcoder
Mar 01 2015 19:34
IEnumerable<type>
but like I said, it has to be a different type
Otherwise you are locking in
and we don’t want locked in from making changes
Joel Bennett
@Jaykul
Mar 01 2015 19:35
sure
for OneGet, all I need is the name and source (not the username/password/disabled setting
Rob Reynolds
@ferventcoder
Mar 01 2015 19:37
For others, they may need the disabled, and to know whether it is authenticated
I wouldn’t expose the user name or the password
Joel Bennett
@Jaykul
Mar 01 2015 19:37
Oh, actually, OneGet does need to know if it's authenticated or not
Rob Reynolds
@ferventcoder
Mar 01 2015 19:37
with disabled versus enabled, you obviously wouldn’t pass along to oneget the ones that are disabled
Joel Bennett
@Jaykul
Mar 01 2015 19:37
right
Rob Reynolds
@ferventcoder
Mar 01 2015 19:37
but they would come back from this method
:)
Joel Bennett
@Jaykul
Mar 01 2015 19:39
so new type: public class Source : Tuple<string, string, bool, bool> { }
hehe
Jaykul @Jaykul is being lazy
Joel Bennett
@Jaykul
Mar 01 2015 19:40
ok, so let's just gloss over that for a sec, I'll come back and write it after I'm done getting help from you ;)
I can't add:
IEnumerable<Source> source_list(ChocolateyConfiguration configuration);
to the interface
I could add it as a property, or just call it something else
Or ...
I could expose it the way the NuGetService does ... where I always return the enum and I take a boolean (default true) as to whether to log or not
and just have the single method
I guess that makes sense, looking at nugetservice
Joel Bennett
@Jaykul
Mar 01 2015 19:46
IEnumerable<Source> source_list(ChocolateyConfiguration configuration, bool logResults);
I'm going with that, unless you don't like it
ok, next level ...
There doesn't currently seem to be any implementation that exposes output on the Lets.GetChocolatey() api
This message was deleted
I'm thinking I have to add a .RunList() or something
Joel Bennett
@Jaykul
Mar 01 2015 19:52
But obviously the return results are going to be different every time I need something like this?
Rob Reynolds
@ferventcoder
Mar 01 2015 19:52
Yup, enhance results
Set a method next to run that exposes the ienumerable
Joel Bennett
@Jaykul
Mar 01 2015 19:53
IEnumerable<object> ?
IEnumerable<T>?
Rob Reynolds
@ferventcoder
Mar 01 2015 19:53
No, you are thinking abstract. Concrete for now
A method for each different call
Joel Bennett
@Jaykul
Mar 01 2015 19:54
so Lets.GetChocolatey().GetSources()
Rob Reynolds
@ferventcoder
Mar 01 2015 19:54
.install/.upgrade/.list
Joel Bennett
@Jaykul
Mar 01 2015 19:54
or .ListSources() rather
Rob Reynolds
@ferventcoder
Mar 01 2015 19:54
.sources
Well not really list, more of a get but we can just drop the verb
Joel Bennett
@Jaykul
Mar 01 2015 19:55
Lets.GetChocolatey().Sources() ?
That makes sense
Rob Reynolds
@ferventcoder
Mar 01 2015 19:55
At least until we come up with a good verb. Yup
Joel Bennett
@Jaykul
Mar 01 2015 19:55
OK, good enough for now ;)
Joel Bennett
@Jaykul
Mar 01 2015 20:08
Hmm, ok, that's not quite all the layers
Currently all the magic of figuring out which command and configuring the command happens in the GenericRunner
I need to either make a new runner, or add something to if(config.Noop){ } else { run }
Joel Bennett
@Jaykul
Mar 01 2015 20:14
something like a SourceRunner