Thanks for the reply. The debugger doesn't need the types loaded in order to use them since it passes that work down to puppet when evaluating code. The only thing I want to do here is just present a list so the user knows what types and dataypes are available to them.
*I am going to play around with your suggestions to see what I can come up with.* On Thursday, March 30, 2017 at 10:21:12 PM UTC-7, Thomas Hallgren wrote: > > Hi Corey, > > Yes, your solution is indeed hackish as it performs surgery on > undocumented implementation internals that might change without notice :-). > Please don't do that. > > We currently have no way of presenting a full list. In order to do that, > we must implement new functionality on the Puppet::Pops::Loaders::Loader. > The loaders form a directed acyclic graph where the leafs are the private > loaders of each module. Different loaders see different things. Code loaded > from one module will not automatically see all things loaded from other > modules. It will just see modules that it is immediately dependent on. This > is probably something that the debugger needs to be aware of. > > I would envision that the debugger would obtain the loader by doing > Puppet::Pops::Loaders.find_loader(<a > module name>) or by asking what loader that is attached to the current > AST using the > Puppet::Pops::Adapters::LoaderAdapter.loader_for_model_object method. It > would then obtain the list from there. The list will vary depending on > loader. > > A complicating factor might be that most types are loaded on demand. I.e. > the loader doesn't know about them until the type is referenced loaded (or > missing) as a response to that reference. Perhaps we'll need to design > something that loads everything eagerly. > > In any case, please enter a ticket (or tickets) where you explain what the > debugger would need. I think we'll need to work together on this to create > a good solution. > > Short term, for the statically loaded things, take a look at > Puppet::Pops::Types::TypeFactory.type_map. It's "@api private" but it's > not likely to change any time soon. > > - thomas > > > On Fri, Mar 31, 2017 at 3:19 AM, Corey Osman <co...@logicminds.biz > <javascript:>> wrote: > >> Hi, >> >> I have found a way to list datatypes for the puppet-debugger ( >> https://github.com/nwops/puppet-debugger) but my approach seems >> hackish. Additionally my approach only seems to pick up the core datatypes >> and not 3rd party types loaded from stdlib puppet module and such. >> >> >> Is there a better way than this? >> >> https://gist.github.com/logicminds/2a7bf4124f3bdb01f1a77d0bb521dffc >> >> >> Corey >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-dev+...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-dev/D35D28B2-7D65-47C9-8A1A-D1E1C2278AD1%40nwops.io >> >> <https://groups.google.com/d/msgid/puppet-dev/D35D28B2-7D65-47C9-8A1A-D1E1C2278AD1%40nwops.io?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/9a02b21a-6e0a-478a-adca-9117df9ae129%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
