Latest Commit to psake

[Jorge]

My latest commit to psake adds configuration via a psake.config xml
file and more advanced module handling - the format of the config file
is shown below:
---------------------------------------------------------------------------------------------------------------------------------------------
<config>
<defaultbuildfilename>default.ps1</defaultbuildfilename> <!-- if
omitted psake uses "default.ps1" -->

<tasknameformat>Executing task: {0}</tasknameformat> <!-- if omitted
psake uses "Executing {0}" -->

<exitcode>1</exitcode> <!-- if omitted pake uses "1" -->

<!--
The <modules> element controls how psake loads modules.

If the "autoload" attribute = true then psake loads all modules found
in the "directory" attribute
the "directory" attribute is optional, default value is ".\modules"

example:
<modules autoload="true" directory="c:\modules" />

psake's default behavior if the <modules> element is missing is not
load any modules

If autoload = false then psake will not autoload modules but will
instead look for the nested "module"
element to determine which modules to load. The "module" element is
optional and if omitted then no modules
will be loaded.

example1 - Turn off autoloading and explicitly load module1.psm1 and
module2.psm1:
<modules autoload="false">
<module path="c:\module1dir\module1.psm1" />
<module path="c:\module2dir\module2.psm1" />
</modules>

example2 - Turn off autoloading and don't load any modules:
<modules autoload="false" />
-->

<modules autoload="false" />
</config>

---------------------------------------------------------------------------------------------------------------------------------------------
The psake.config file that is in the Git Repo looks like this:
---------------------------------------------------------------------------------------------------------------------------------------------
<config>
<defaultbuildfilename>default.ps1</defaultbuildfilename>
<tasknameformat>Executing task: {0}</tasknameformat>
<exitcode>1</exitcode>
<modules autoload="false" />
</config>
---------------------------------------------------------------------------------------------------------------------------------------------
I've also removed the teamcity.ps1 script file and added it to the
psake-contrib project as a module

As always, please review and let me know what you all think.

-Jorge

[Steve Wagner]

�hm. A short question. The advantage of psake is that is dose not use
xml and is so much more flaxible and better to read. So why using xml as
configuration file format?

-Steve

[stej]

PowerShell can read xml files very nicely, maybe that's the reason.
But you are correct, that there are other ways too. For very simple
scenarios one might use ConvertFrom-StringData, but e.g. this doesn't
work well:

> @"
Msg3 = The specified variable does not exist.
arr = @(1,2,3)
hash = @{a = 'b'; c = 145 }
"@ | Set-Content c:\temp\config.txt
> $a = ConvertFrom-StringData ((gc c:\temp\config.txt) -join "`n")
> $a.hash.GetType() #returns string, not hashtable
IsPublic IsSerial Name BaseType
-------- -------- ---- --------
True True String System.Object

Imho simple xml is not that bad :)

[Jorge Matos]

I considered a lot of options for storing the configuration and ended up using XML since it's really really easy to consume xml files from PowerShell and access the xml data as an object with properties.

 

[James Kovacs]

I like the idea of a config file so that folks can customize the defaults. It is rather odd for it to be in XML given the thrust of the project, even if it is easy. :) Why can't we dot-source a ps1 file?

e.g. In psake.psm1:

$defaultBuildFilename = 'default.ps1'
. psake-config.ps1

Then in psake-config.ps1:
$defaultBuildFilename = 'override.foo'

Wouldn't that work just as well as a XML file? Thoughts?

James
--
James Kovacs, B.Sc., M.Sc., MCSD, MCT
Microsoft MVP, ASP/ASP.NET
http://www.jameskovacs.com
jko...@post.harvard.edu | @jameskovacs
403-397-3177 (mobile)

On Tue, Aug 24, 2010 at 8:23 AM, Jorge Matos <matos...@gmail.com> wrote:

I considered a lot of options for storing the configuration and ended up using XML since it's really really easy to consume xml files from PowerShell and access the xml data as an object with properties.

 

--
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 Matos]

Yes, actually it would just as well, the configuration ends up being part of the $psake variable with a name of "config" - and what you are suggesting could be done in the following manner:

 

James,

 

You have a good point - I'll take another look at it :)

 

-Jorge

--
Jorge Matos
Senior .NET Architect, MCSD.NET, MCSD Visual Studio 6.0
(440) 666-3107
matos...@hotmail.com     
Blog: http://matosjorge.spaces.live.com
--------------------------------------------------------------------------------
"Any intelligent fool can make things bigger and more complex...
It takes a touch of genius - and a lot of courage to
move in the opposite direction."... - Albert Einstein

[Jim Christopher]

+1.

parsing XML is easy, spelunking it quickly and safely isn't.  In addition, I'd rather not have a schema dependency that could potentially change.

jimbo

--
Jim Christopher
jimchri...@gmail.com
http://www.beefycode.com

[Jorge Matos]

My last post didn't make too much sense, I will take another look at configuration and see about converting the psake.config file into psake-config.ps1 - I'm thinking that the file would contain code to load a hashtable or a PSObject into the $psake.config variable. 

 

e.g.

 

psake-config.ps1

------------------------

 

$psake.config = new-object psobject -property @{
  defaultbuildfilename="default.ps1";
  tasknameformat="Executing {0}";
  exitcode="1";
  modules=(new-object psobject -property @{
     autoload=$true; 
     directory="c:\modules"
  })
}

 

or

 

$psake.config = new-object psobject -property @{
  defaultbuildfilename="default.ps1";
  tasknameformat="Executing {0}";
  exitcode="1";
  modules=(new-object psobject -property @{
    autoload=$false; 
    module=(new-object psobject -property @{path="c:\module1dir\module1.ps1"}), 
           (new-object psobject -property @{path="c:\module1dir\module2.ps1"})
  })
}

 

 

Jim - You are right about a dependency on an XML schema, but we will still have a dependency regardless on the names of the configuration variables - that can't be avoided.

 

I'd like to build some consensus around this if possible.  Do we want configuration to be in XML or PS code?

[Peter Seale]

Hello all. +1 to PS code-based configuration. If someone wants to store their configuration in XML, they can code something up to read the configuration from an XML file, and the rest of us won't be limited to XML.

--

[Jorge]

I just pushed up new code in psake.psm1 that looks for a file called
psake-config.ps1 and dot-sources it if its found. The function is
called once when the psake.psm1 module is loaded.

function Load-Configuration
{
if (test-path ".\psake-config.ps1")
{
. .\psake-config.ps1
}
else
{

$psake.config = new-object psobject -property @{
defaultbuildfilename="default.ps1";
tasknameformat="Executing {0}";
exitcode="1";
modules=(new-object psobject -property @{ autoload=$true;

directory=".\modules" })
}
}
}

-----------------------------------------------------------------------------------------------------------------------
The contents of the psake-config.ps1 looks like the following:
-----------------------------------------------------------------------------------------------------------------------

$psake.config = new-object psobject -property @{
defaultbuildfilename="default.ps1";
tasknameformat="Executing {0}";
exitcode="1";
modules=(new-object psobject -property @{ autoload=$true;

directory=".\modules" })
}

<#

$psake.config = new-object psobject -property @{
defaultbuildfilename="default.ps1";
tasknameformat="Executing {0}";
exitcode="1";
modules=(new-object psobject -property @{
autoload=$false;
module=(new-object psobject -property @{path="c:\module1dir
\module1.ps1"}),
(new-object psobject -property @{path="c:\module1dir
\module2.ps1"})
})
}

#>

-----------------------------------------------------------------------------------------------------------------------
The commented out code above is the code you would use to explicitly
load modules instead of autoloading modules from a folder.

I think the code in Load-Configuration probably needs a try/catch in
case the code in psake-config.ps1 throws an error.

I will add help on the wiki to explain how configuration works in
detail (assuming everyone is ok with this code).