Feature Requests
23 views
Skip to first unread message
Jorge
May 30, 2010, 4:14:55 PM5/30/10
to psake-dev
Just wanted to know what everyone would like to see in the next
version of psake.
Some of my thoughts lately are:
1) Message Localization
All error and build messages should be localized so that we can
support other languages
2) Module Integration
Determine how to integrate modules written by other developers to
make running a build easier
3) Configuration
Implement an optional configuration system so that you don't need
to use the $psake variable to configure things like logging errors to
a file or using the exit() function when an error occurs, etc...
4) Improved Error Handling
Some folks have expressed a desire to see more detailed error
information displayed to the console when an exception occurs.
Currently this detailed information is written to a file when the
$psake.log_error is set to $true. We could introduce a new parameter
to Invoke-psake called VerboseError that would be checked when an
error occurred and would display the detailed error information to the
console. Or we could simply start displaying the full detailed error
information to the console all the time.
Please let me know what you all think.
version of psake.
Some of my thoughts lately are:
1) Message Localization
All error and build messages should be localized so that we can
support other languages
2) Module Integration
Determine how to integrate modules written by other developers to
make running a build easier
3) Configuration
Implement an optional configuration system so that you don't need
to use the $psake variable to configure things like logging errors to
a file or using the exit() function when an error occurs, etc...
4) Improved Error Handling
Some folks have expressed a desire to see more detailed error
information displayed to the console when an exception occurs.
Currently this detailed information is written to a file when the
$psake.log_error is set to $true. We could introduce a new parameter
to Invoke-psake called VerboseError that would be checked when an
error occurred and would display the detailed error information to the
console. Or we could simply start displaying the full detailed error
information to the console all the time.
Please let me know what you all think.
stej
May 31, 2010, 3:17:51 AM5/31/10
to psake-dev
Maybe James could ask on his blog too to catch broader audience.
ad 2,3,4 it's great idea.
2) module integration
Could be done without psake support, but it is ugly when one needs to
pass parameters during module import
3) configuration
Yes. I would consider configuration in a file as a default settings
that could be also overriden during calling Invoke-Psake (even via
properties, parameters). The question is if there could be more config
files and user then specifies during call to Invoke-Psake which one to
use, or just one.
4) error handling
Most of the time you need to finish all the tasks without errors, so
I would simply write all the errors to console.
ad 1
I think this is not worth implementing - all the 3rd party tools
(e.g. msbuild) will probably write errors in english and besides that
every IT pro has to understand english.
---
5) Output in colors
Personally I miss colored output. I would like to have every task
name written in e.g. Green (write-host Executing $taskName -foreg
Green), as well as the report or any other output from psake. Colors
help me when I need to scan the output visually. If psake should
continue after error, the error is written in Red.
It would behave the same way as e.g. msbuild.
Sounds easy, but it isn't - I don't know exactly how to implement it
yet. The problem is that output from psake could be redirected to
file. Strings written via Write-Host are not caught and thus not saved
to file. (write-host 'test' -fore Green > out.log doesn't work).
Anybody interested in colored output?
ad 2,3,4 it's great idea.
2) module integration
Could be done without psake support, but it is ugly when one needs to
pass parameters during module import
3) configuration
Yes. I would consider configuration in a file as a default settings
that could be also overriden during calling Invoke-Psake (even via
properties, parameters). The question is if there could be more config
files and user then specifies during call to Invoke-Psake which one to
use, or just one.
4) error handling
Most of the time you need to finish all the tasks without errors, so
I would simply write all the errors to console.
ad 1
I think this is not worth implementing - all the 3rd party tools
(e.g. msbuild) will probably write errors in english and besides that
every IT pro has to understand english.
---
5) Output in colors
Personally I miss colored output. I would like to have every task
name written in e.g. Green (write-host Executing $taskName -foreg
Green), as well as the report or any other output from psake. Colors
help me when I need to scan the output visually. If psake should
continue after error, the error is written in Red.
It would behave the same way as e.g. msbuild.
Sounds easy, but it isn't - I don't know exactly how to implement it
yet. The problem is that output from psake could be redirected to
file. Strings written via Write-Host are not caught and thus not saved
to file. (write-host 'test' -fore Green > out.log doesn't work).
Anybody interested in colored output?
Steve Wagner
May 31, 2010, 4:44:45 AM5/31/10
to psak...@googlegroups.com
What about using a convention to load modules automatically?
And i think it would be nice to have Colored Console output. This would
help to notice errors faster.
Joshua Poehls
Jun 2, 2010, 12:34:48 PM6/2/10
to psak...@googlegroups.com
I'd like to have colored output as well.
1) I agree with stej that this doesn't seem to be worth the effort. Its standard for build tools (in my experience) to only output in english. So long as that is true I don't see a reason to localize psake.
2) module integration would be nice. at least an option to load the modules by convention from some /modules folder (or something) would be great. that would help keep the build scripts clean of explicit module includes which is something I prefer.
3,4) I can definitely see benefits here. I'd also be ok with the full error details always being written to the console and dumping the output log file altogether.
- Joshua Poehls
--
You received this message because you are subscribed to the Google Groups "psake-dev" group.
To post to this group, send email to psak...@googlegroups.com.
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psake-dev?hl=en.
Jorge
Jun 15, 2010, 2:12:04 AM6/15/10
to psake-dev
I've just pushed up some changes to github - here are my commit
comments:
Updated FormatTaskName function to take either a format string
(example: FormatTaskName "Running Task: {0}") or a ScriptBlock that is
defined to take the $taskName as a parameter
(example: FormatTaskName {
param($taskName)
write-host $taskName -foregroundcolor green
})
Added formattaskname_string.ps1 and formattaskname_scriptblock.ps1 as
examples of how to use the FormatTaskName function
Renamed ExecuteTask to Invoke-Task and made it a public function so
that you can call a task from within another task
Added specs/calling_invoke-task_should_pass.ps1 to test calling a task
from within another task
When an error occurs detailed information is written to the host with
write-host
The $psake variable log_error is no longer used
Updated Resolve-Error to return a formatted string that can be used
with write-host
Moved call to context.pop() from Invoke-psake() to Cleanup-
Environment()
Moved all error messages to a DATA section and added call to import-
localizeddata
Added suppress_error_messages config setting to $psake variable so
that psake-buildTester.ps1 does not display error messages
comments:
Updated FormatTaskName function to take either a format string
(example: FormatTaskName "Running Task: {0}") or a ScriptBlock that is
defined to take the $taskName as a parameter
(example: FormatTaskName {
param($taskName)
write-host $taskName -foregroundcolor green
})
Added formattaskname_string.ps1 and formattaskname_scriptblock.ps1 as
examples of how to use the FormatTaskName function
Renamed ExecuteTask to Invoke-Task and made it a public function so
that you can call a task from within another task
Added specs/calling_invoke-task_should_pass.ps1 to test calling a task
from within another task
When an error occurs detailed information is written to the host with
write-host
The $psake variable log_error is no longer used
Updated Resolve-Error to return a formatted string that can be used
with write-host
Moved call to context.pop() from Invoke-psake() to Cleanup-
Environment()
Moved all error messages to a DATA section and added call to import-
localizeddata
Added suppress_error_messages config setting to $psake variable so
that psake-buildTester.ps1 does not display error messages
Beefarino
Jul 7, 2010, 6:02:29 PM7/7/10
to psake-dev
Greetings all. My name is Jim Christopher. I'm looking to
contribute.
I've noticed that the wiki contains a topic about passing parameters
to a psake script (http://wiki.github.com/JamesKovacs/psake/how-can-i-
pass-parameters-to-my-psake-script) that contains no information.
Looking through the source, I found no indication of a way to pass
local state through the invoke-psake function to the underlying psake
script outside of using a global variable.
I've added a way to do this to my local psake module, wondering what
the general response will be and whether I should submit a patch.
The general idea is to be able to invoke this:
invoke-psake mybuild.ps1 Build,Deploy -configuration debug -deploy
internal
and capture the extra parameters (configuration and deploy) in the
psake script to alter the build script:
#mybuild.ps1
param( $configuration, $deploy );
task VerifyConfiguration{
Assert ( @('Debug', 'Release') -contains $configuration ) "Unknown
configuration, $configuration";
}
task Build -depends VerifyConfiguration {
msbuild myproj.csproj /p:Configuration=$configuration /t:Build
}
So does this seem useful?
Obliged,
jim
contribute.
I've noticed that the wiki contains a topic about passing parameters
to a psake script (http://wiki.github.com/JamesKovacs/psake/how-can-i-
pass-parameters-to-my-psake-script) that contains no information.
Looking through the source, I found no indication of a way to pass
local state through the invoke-psake function to the underlying psake
script outside of using a global variable.
I've added a way to do this to my local psake module, wondering what
the general response will be and whether I should submit a patch.
The general idea is to be able to invoke this:
invoke-psake mybuild.ps1 Build,Deploy -configuration debug -deploy
internal
and capture the extra parameters (configuration and deploy) in the
psake script to alter the build script:
#mybuild.ps1
param( $configuration, $deploy );
task VerifyConfiguration{
Assert ( @('Debug', 'Release') -contains $configuration ) "Unknown
configuration, $configuration";
}
task Build -depends VerifyConfiguration {
msbuild myproj.csproj /p:Configuration=$configuration /t:Build
}
So does this seem useful?
Obliged,
jim
stej
Jul 16, 2010, 7:18:10 PM7/16/10
to psake-dev
Hello Jim, nobody more compotent has answered you so far, so I will -
have you checked $parameters and $properties of function Invoke-Psake?
What is the difference?
These hashtables are used to pass 'parameters' that can be used inside
tasks.
Apart from that syntax 'param( $configuration, $deploy )' looks more
natural&powershellish. Do you parse remaining arguments in $args (in
invoke-psake) and try to create a hashtable that is passed via
splatting to the build script?
stej
have you checked $parameters and $properties of function Invoke-Psake?
What is the difference?
These hashtables are used to pass 'parameters' that can be used inside
tasks.
Apart from that syntax 'param( $configuration, $deploy )' looks more
natural&powershellish. Do you parse remaining arguments in $args (in
invoke-psake) and try to create a hashtable that is passed via
splatting to the build script?
stej
Jim Christopher
Jul 17, 2010, 12:11:58 PM7/17/10
to psak...@googlegroups.com
Stej;
Thanks for the reply.
I have checked out the $parameters and $properties variables; the $properties in particular looked promising, but it didn't work the way I expected. E.g., I wanted to have Tasks modify the property list (e.g., the Debug task sets $properties['configuration'] = 'DEBUG'), but the changes would not stick across Tasks. Even if that did work, it felt cumbersome. I don't like the hidden coupling - I'd rather have a set of parameters dictated at the front of the script in a nice juicy params().
The solution I came up with is pretty straightforward:
First, I added a $params parameter to the invoke-psake param list; the [Parameter] attribute has the ValueFromRemainingArguments property set, so it sucks up any unattached arguments:
function Invoke-psake
{
param(
[Parameter(Position=0,Mandatory=0)]
[string]$buildFile = 'default.ps1',
[Parameter(Position=1,Mandatory=0)]
[string[]]$taskList = @(),
[Parameter(Position=2,Mandatory=0)]
[string]$framework = '3.5',
[Parameter(Position=3,Mandatory=0)]
[switch]$docs = $false,
[Parameter( ValueFromRemainingArguments=$true )]
$params
)
Then I just change the way the psake script is invoked; instead of invoking the script directly, I create a string containing the psake script reference and the extra parameters from the invoke-psake call, then pass that string to invoke-expression:
$x =". $($script:psake.build_script_file.FullName) $params";
Invoke-Expression $x;
jim
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
Thanks for the reply.
I have checked out the $parameters and $properties variables; the $properties in particular looked promising, but it didn't work the way I expected. E.g., I wanted to have Tasks modify the property list (e.g., the Debug task sets $properties['configuration'] = 'DEBUG'), but the changes would not stick across Tasks. Even if that did work, it felt cumbersome. I don't like the hidden coupling - I'd rather have a set of parameters dictated at the front of the script in a nice juicy params().
The solution I came up with is pretty straightforward:
First, I added a $params parameter to the invoke-psake param list; the [Parameter] attribute has the ValueFromRemainingArguments property set, so it sucks up any unattached arguments:
function Invoke-psake
{
param(
[Parameter(Position=0,Mandatory=0)]
[string]$buildFile = 'default.ps1',
[Parameter(Position=1,Mandatory=0)]
[string[]]$taskList = @(),
[Parameter(Position=2,Mandatory=0)]
[string]$framework = '3.5',
[Parameter(Position=3,Mandatory=0)]
[switch]$docs = $false,
[Parameter( ValueFromRemainingArguments=$true )]
$params
)
Then I just change the way the psake script is invoked; instead of invoking the script directly, I create a string containing the psake script reference and the extra parameters from the invoke-psake call, then pass that string to invoke-expression:
$x =". $($script:psake.build_script_file.FullName) $params";
Invoke-Expression $x;
jim
--
You received this message because you are subscribed to the Google Groups "psake-dev" group.
To post to this group, send email to psak...@googlegroups.com.
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/psake-dev?hl=en.
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
stej
Jul 19, 2010, 3:29:42 AM7/19/10
to psake-dev
James, did you fork james's code at github?
I'm asking, because imho ""I wanted to have Tasks modify the property
Why: tasks in the build file are just declared, rather than executed.
So when the code of the task is executed, variable configuration is
probably missing, because it is executed in other scope (http://
github.com/JamesKovacs/psake/blob/master/psake.psm1#L275 ). I guess it
would be needed to create a closure to capture the variable but that
would create its own copy for each task and that's why changing the
variable value would not work.
I'm just thinking about the problems, maybe there are none and you
solved it in other way.
> > psake-dev+...@googlegroups.com<psake-dev%2Bunsu...@googlegroups.com>
> > .
I'm asking, because imho ""I wanted to have Tasks modify the property
list (e.g., the Debug task sets $properties['configuration'] =
'DEBUG')"" will not work - I would like to check it.
Why: tasks in the build file are just declared, rather than executed.
So when the code of the task is executed, variable configuration is
probably missing, because it is executed in other scope (http://
github.com/JamesKovacs/psake/blob/master/psake.psm1#L275 ). I guess it
would be needed to create a closure to capture the variable but that
would create its own copy for each task and that's why changing the
variable value would not work.
I'm just thinking about the problems, maybe there are none and you
solved it in other way.
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/psake-dev?hl=en.
>
> --
> Jim Christopher
> jimchristop...@gmail.comhttp://www.beefycode.com> >http://groups.google.com/group/psake-dev?hl=en.
>
> --
> Jim Christopher
Jim Christopher
Jul 19, 2010, 3:32:53 PM7/19/10
to psak...@googlegroups.com
Stej;
I did not fork, but that's kind of where I'm going with this - what's the process for contributing? Just fork & go?
I'd like to help out on this project, not just with this item.
jim
p.s. to avoid confusion with the Real James(tm), please call me "jim" or "jimbo"
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
I did not fork, but that's kind of where I'm going with this - what's the process for contributing? Just fork & go?
I'd like to help out on this project, not just with this item.
jim
p.s. to avoid confusion with the Real James(tm), please call me "jim" or "jimbo"
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
stej
Jul 20, 2010, 12:38:45 AM7/20/10
to psake-dev
(oops, sorry for renaming you)
Jorge or James or other psake core members will tell you more. In
fact:
- create a fork at github
- commit changes to your fork until you are satisfied
- make a request to integrate your changes to psake (from your fork)
via button "Pull Request"
To be honest I don't know what is the measure to distinguish what will
be integrated to psake origin and what not :)
> > <psake-dev%2Bunsu...@googlegroups.com<psake-dev%252Buns...@googlegroups.com>
Jorge or James or other psake core members will tell you more. In
fact:
- create a fork at github
- commit changes to your fork until you are satisfied
- make a request to integrate your changes to psake (from your fork)
via button "Pull Request"
To be honest I don't know what is the measure to distinguish what will
be integrated to psake origin and what not :)
Jim Christopher
Jul 20, 2010, 9:03:00 AM7/20/10
to psak...@googlegroups.com
Kewl, thanks stej. Let me see what I can do here...
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
To unsubscribe from this group, send email to psake-dev+...@googlegroups.com.
--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com
Reply all
Reply to author
Forward
0 new messages