'task' and 'connection' objects are poorly documented

[shattered]

'connection' is at least mentioned in the API doc (http://rexify.org/docs/api/1.3/rex/commands.pm.html#connection) but 'task' is not.

Plus, it appears that task->user is never set, and task->name is not updated when the task has been launched via needs() -- in this case it still reports dependee's name.

[ferki]

Rex::Task is documented here: http://rexify.org/docs/api/1.3/rex/task.pm.html (updated on 528017a for 1.4rc branch). Maybe that was what you were looking for?

You can take a look at the implementation of connection-releated stuff under Rex::Interface::Connection namespace, but you're right, they are not yet documented. Can you maybe help with adding the bits you missed?

ps.: I'm not sure if the reporting output details when using needs() should belong to this very same issue. Can you open a separate one about that, please? If possible, please include an example with your code, mentioning the wrong results, and the expected ones.

[shattered]

Ah, indeed Rex::Task is the document I was thinking of. task->user is still empty for me, I'll try to create a test case.

[shattered]

Turns out that task->user is set unless feature "0.31" or newer is enabled. Why is that?

[krimdomu]

@shattered
before 0.31 it was possible to do this:

user "foo";
password "bar";
task "mytask", sub {};  # connect with user: foo

user "otheruser";
password "otherpass";
task "othertask", sub {}; # connect with user: otheruser

This was removed in favour of the auth for => "task" function.

So since since 0.31 the task has a new attribute user. In the time before 0.31 the authentication was not an attribute of the task object.

[shattered]

Yeah, but why it's reported as empty? :)

[ferki]

Thanks for you patience, @shattered!

TL;DR:

This issue seems to be a mixture of several smaller questions together, which makes it harder than necessary to process and track properly. Given the combination of

• the aforementioned mix
• the age of this question without activity
• lacking further information to reproduce use cases

I am closing this issue now, with more detailed notes below.

Any readers of this who still have questions or concerns, please reach out on one of our support channels.

Longer version

Nevertheless, let me summarize some notes below.

'connection' objects [...] poorly documented

Right, Rex::Interface::Connection classes still could use some documentation. I would rather deal with that separately, and will open another issue about that single aspect.

'task' objects [...] poorly documented

Docs are available in Rex::Task.

task->user is never set

It's certainly hard to guess a correct answer for a question from years ago without a code example to reproduce the exact same use case that might have been confusing back then.

There were two notable code changes which might have addressed your concern since then:

• Fix distributor setting when versioned feature flag is active #1285 fixing how default authentication information is attached to tasks
• 7dadd51 fixing the fallback username detection logic (which then gets attached as part of the default auth)

I'm testing with today's latest version with the following code:

use Rex;
use Rex::TaskList;

task 'test', sub {
    say 1;
};

use DDP;
my $task = Rex::TaskList->create->get_task('test');
p $task->user();

and it returns the expected value (my local username autodetected as a fallback).

task->name is not updated when the task has been launched via needs()

There was no example code attached to help reproduce the same use case, but at first glance it feels possibly "by design" to me. While executing needs() the additional tasks are pulled in as dependencies, and executed on the same connection as if they were a single larger task. This helps with reusability of smaller chunks – but it doesn't imply that there's no bug, or that rex can't do something better.

[ferki]

(Actually clicking the close button now 🤣 )