Jira (PUP-8606) Module-defined data types are very verbose when displayed

13 views
Skip to first unread message

Michael Smith (JIRA)

unread,
Mar 23, 2018, 3:55:02 PM3/23/18
to puppe...@googlegroups.com
Michael Smith created an issue
 
Puppet / Bug PUP-8606
Module-defined data types are very verbose when displayed
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2018/03/23 12:54 PM
Priority: Normal Normal
Reporter: Michael Smith

As noted in BOLT-413, the printable representation for certain data types is very verbose. For example, TargetSpec defined as an alias in Bolt displays as

TargetSpec = Boltlib::TargetSpec = Variant[String[1], Object[{name => 'Target', attributes => {'uri' => String[1], 'options' => {type => Hash[String[1], Data], value => {}}}, functions => {'host' => Callable[[0, 0], String[1]], 'name' => Callable[[0, 0], String[1]], 'password' => Callable[[0, 0], Optional[String[1]]], 'port' => Callable[[0, 0], Optional[Integer]], 'protocol' => Callable[[0, 0], Optional[String[1]]], 'user' => Callable[[0, 0], Optional[String[1]]]}}], Array[Boltlib::TargetSpec]]

This can be seen by running bolt plan show canary in Bolt 0.18.1 (once we get BOLT-407 fixed).

I'd rather this use a succinct representation, like TargetSpec or TargetSpec = Bolt::TargetSpec.

I see two possibilities for fixing this:

  • a way to define how the Bolt::TargetSpec type should be displayed via to_s
  • provide the original parameter text from the plan declaration as part of the type returned via the params_type accessor on a plan.
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Michael Smith (JIRA)

unread,
Mar 23, 2018, 4:00:02 PM3/23/18
to puppe...@googlegroups.com
Michael Smith commented on Bug PUP-8606
 
Re: Module-defined data types are very verbose when displayed

An example of adding original text to the type at https://github.com/MikaelSmith/puppet/tree/PUP-8606. However I'm concerned about the memory implications of doing that on every type. I haven't dug into how else create_param_type is used.

Henrik Lindberg (JIRA)

unread,
Mar 23, 2018, 6:08:02 PM3/23/18
to puppe...@googlegroups.com

I commented on your commit. I don't think it is a good idea to add a member variable to every type in the type system to hold the source text if that type was obtained from a parameter type expression.

What is the problem you are trying to solve (apart from the string form being verbose as shown) - where/why do you end up with that particular string output?

In general, there is obviously a trade off between being succinct (only showing a type alias for example), vs. showing all of the details. At first we only showed the alias, but then we got complaints that the output was too opaque. You may want to have your own function for determining how much to show - in this case TargetSpec is supposed to be a well known type, as opposed to something a user invented, and you may want to format different types with varying degree of detail/expansion. That is just impossible to have in the types themselves as it depends on the use case / context. (Often a to_s is where such conflicting requirements meet).

To give a good recommendation what to do in your case depends on the details of where/when in occurs.

Henrik Lindberg (JIRA)

unread,
Mar 23, 2018, 6:11:03 PM3/23/18
to puppe...@googlegroups.com

It may also be that we need to support a way to define a useful to_s implementation for registered types that should be opaque.

Michael Smith (JIRA)

unread,
Mar 23, 2018, 6:15:03 PM3/23/18
to puppe...@googlegroups.com
Michael Smith commented on Bug PUP-8606

This happens when we get a list of parameters on a plan via PAL: https://github.com/puppetlabs/bolt/blob/0.18.0/lib/bolt/pal.rb#L204-L225

We iterate over the parameters and get a printable representation of the type. Is there a way to modify the Target and Error types so they aren't expanded? Currently they appear to be, which is where most of the verbosity comes from.

Right now, Target is getting printed as

Object[{name => 'Target', attributes => {'uri' => String[1], 'options' => {type => Hash[String[1], Data], value => {}}}, functions => {'host' => Callable[[0, 0], String[1]], 'name' => Callable[[0, 0], String[1]], 'password' => Callable[[0, 0], Optional[String[1]]], 'port' => Callable[[0, 0], Optional[Integer]], 'protocol' => Callable[[0, 0], Optional[String[1]]], 'user' => Callable[[0, 0], Optional[String[1]]]}}

Henrik Lindberg (JIRA)

unread,
Mar 23, 2018, 6:37:06 PM3/23/18
to puppe...@googlegroups.com

Michael Smith Ok, got it - you get the signature and want to display parameters. Thomas Hallgren can types like Target be made to show less information by default, or should we have a special (polymorph) function to get the desired strings?

Thomas Hallgren (JIRA)

unread,
Mar 24, 2018, 1:43:03 AM3/24/18
to puppe...@googlegroups.com

This looks like a bug to me. An Object type should represent itself with its name only, not the full spec. The type in the example should present itself as:

TargetSpec = Boltlib::TargetSpec = Variant[String[1], Target, Array[Boltlib::TargetSpec]]

Henrik Lindberg (JIRA)

unread,
Mar 24, 2018, 5:21:03 AM3/24/18
to puppe...@googlegroups.com

Henrik Lindberg (JIRA)

unread,
Mar 24, 2018, 5:21:04 AM3/24/18
to puppe...@googlegroups.com

Geoff Nichols (JIRA)

unread,
Mar 27, 2018, 2:04:03 PM3/27/18
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Apr 10, 2018, 4:36:03 PM4/10/18
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Apr 11, 2018, 11:34:03 AM4/11/18
to puppe...@googlegroups.com

Kenn Hussey (JIRA)

unread,
Apr 11, 2018, 11:34:03 AM4/11/18
to puppe...@googlegroups.com
Kenn Hussey updated an issue
Change By: Kenn Hussey
Fix Version/s: PUP 5.5.1
Fix Version/s: PUP 5.5.2

Kenn Hussey (JIRA)

unread,
May 10, 2018, 10:05:03 AM5/10/18
to puppe...@googlegroups.com
Kenn Hussey updated an issue
Change By: Kenn Hussey
Fix Version/s: PUP 5.5.2
Fix Version/s: PUP 5.5.3

Michael Smith (JIRA)

unread,
Jun 21, 2018, 4:08:04 PM6/21/18
to puppe...@googlegroups.com
Michael Smith commented on Bug PUP-8606
 
Re: Module-defined data types are very verbose when displayed

Thomas Hallgren any hope of fixing this sometime soon? Or suggestions how I should go about it?

Thomas Hallgren (JIRA)

unread,
Jun 22, 2018, 5:07:02 AM6/22/18
to puppe...@googlegroups.com

On PTO. Will take a look next week.

Den tor 21 juni 2018 22:08Michael Smith (JIRA) <

Kenn Hussey (JIRA)

unread,
Jul 9, 2018, 10:19:06 AM7/9/18
to puppe...@googlegroups.com

Thomas Hallgren (JIRA)

unread,
Jul 9, 2018, 5:28:03 PM7/9/18
to puppe...@googlegroups.com
Thomas Hallgren updated an issue
Change By: Thomas Hallgren
Fix Version/s: PUP 5.5.3
Fix Version/s: PUP 5.5.z

Kenn Hussey (JIRA)

unread,
Jul 10, 2018, 11:49:35 AM7/10/18
to puppe...@googlegroups.com

Rob Braden (JIRA)

unread,
Aug 8, 2018, 5:01:03 PM8/8/18
to puppe...@googlegroups.com
Rob Braden updated an issue
Change By: Rob Braden
Team: Platform Core Coremunity

Rob Braden (JIRA)

unread,
Aug 8, 2018, 5:01:04 PM8/8/18
to puppe...@googlegroups.com
Rob Braden assigned an issue to Unassigned
Change By: Rob Braden
Assignee: Thomas Hallgren

Rob Braden (JIRA)

unread,
Aug 8, 2018, 5:02:03 PM8/8/18
to puppe...@googlegroups.com
Rob Braden updated an issue
Change By: Rob Braden
Team: Coremunity Platform Core

Rob Braden (JIRA)

unread,
Aug 8, 2018, 5:02:03 PM8/8/18
to puppe...@googlegroups.com

Michael Smith (JIRA)

unread,
Aug 21, 2018, 1:03:02 PM8/21/18
to puppe...@googlegroups.com
Michael Smith commented on Bug PUP-8606
 
Re: Module-defined data types are very verbose when displayed

Some additional notes for when I get back to this: the issue probably needs to be addressed somewhere in TypeMismatchDescriber, TypeFormatter or possibly StringConverter. The type is expanded when it should not be. There is logic for type expansion in the Mismatch Describer.

Josh Cooper (Jira)

unread,
Oct 23, 2020, 7:59:02 PM10/23/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
 
Change By: Josh Cooper
Fix Version/s: PUP 5.5.z
Fix Version/s: PUP 6.y
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

David McTavish (Jira)

unread,
Dec 6, 2021, 3:09:02 PM12/6/21
to puppe...@googlegroups.com
David McTavish updated an issue
Change By: David McTavish
Labels: final_triage
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo

David McTavish (Jira)

unread,
Dec 6, 2021, 3:09:02 PM12/6/21
to puppe...@googlegroups.com

Josh Cooper (Jira)

unread,
Jan 13, 2022, 2:11:02 AM1/13/22
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-8606
 
Re: Module-defined data types are very verbose when displayed

michael.smith lucy Is this still needed for Bolt? It seems somewhat related (but different) to the PR Arthur put up for PUP-11127.

This message was sent by Atlassian Jira (v8.20.2#820002-sha1:829506d)
Atlassian logo

Michael Smith (Jira)

unread,
Jan 13, 2022, 12:46:01 PM1/13/22
to puppe...@googlegroups.com
Michael Smith commented on Bug PUP-8606

I don't think it was ever addressed, and does seem related to that issue.

Molly Waggett (Jira)

unread,
Feb 22, 2022, 1:46:01 PM2/22/22
to puppe...@googlegroups.com

Molly Waggett (Jira)

unread,
Feb 22, 2022, 1:47:02 PM2/22/22
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages