[wpkg-users] [Bug 138] New: Removal actions fail if not preceeded by install/ upgrade actions. - New environment processing idea

bugzilla-daemon at bugzilla.wpkg.org bugzilla-daemon at bugzilla.wpkg.org
Wed Jan 7 00:32:52 CET 2009


http://bugzilla.wpkg.org/show_bug.cgi?id=138

           Summary: Removal actions fail if not preceeded by install/upgrade
                    actions. - New environment processing idea
           Product: WPKG
           Version: 1.1.x-M
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo at wpkg.org
        ReportedBy: k.e.jones at brighton.ac.uk
         QAContact: wpkg-users at lists.wpkg.org


Created an attachment (id=125)
 --> (http://bugzilla.wpkg.org/attachment.cgi?id=125)
A simple environement stack concept

Hi,

 This is a bit of code I've been playing with to solve a TODO on the
environment variable handling function.

 The current implementation doesn't handle variables with embedded "=" or
quotes. It's unlikely that people might have a problem with this but it's
possible and it's highlighted as a TODO.


 Although I've got a smart parser function to hand that copes with quotes,
parsing the environment variables supplied by WScript is made even more complex
because DOS uses the "=" to hide a few variables from the "set" command.
i.e. "." which evaluates to the current directory and "ERRORLEVEL" which is the
last DOS error. Both these show up as "=<variable>==<value>" so just splitting
on the "=" doesn't work well even if you can handle quoted strings.

 This implementation tries to skirt around the whole idea of saving/restoring
the environment and hence the need to parse awkward variables like this. It
just tries to track changes instead.

 It's not without issues but it's got potential :-)

 The issues I have with it are;

 a) I've used custom functions so it's not going to be as easy to understand
for anyone who's new to JScript and wants to contribute ideas. That's something
I'd like to avoid.

 b) I've had to make assumptions and although they seem pretty good ones it
still makes me feel a bit uncomfortable that it's compromise rather than a
total solution.

 c) It's an example. Much as I wanted to supply it as a patch, it didn't seem
worth it seeing as it was such a "different" way of dealing with things. It's
probably better to offer it as an idea instead.

 Overall though, it's relatively flexible and should match up well with keeping
environment variable processing neatly in tune with a heirarchical structure if
that's useful to WPKG.

 Potential expansions include;

 a) Bookmarking so you can effectively cope with nested variable definitions
and handle a them as a part of of dependancy model. 
 b) Replayability/Re-enforcement so you could reset the environment and then
replay the changes if there's a need. (Might be handy if you want to implement
a completely sandbox concept)
 c) It's object orientated so it might simplify the "model" code a bit. (not
much but a bit!)


 If it's not useful, well, at least it's a thought :-)

Have fun,

Keith


-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.



More information about the wpkg-users mailing list