Information for a package manager to retain.

 Please feel free to edit. These are structure records that would be needed for a hypothetical package manager.
Structure
string packageName
uint32 packageVersion    //version number of the package.
string patchLevel
string packageID    //packageID in the repository
string packageURL
string packageContact  //email address of package maintainer (should this be mangled?)  
string md5hash    //the hash of the downloaded package for some security.
uint32 dateOfFirstInstall
uint32 lastUpdated
uint16 isCurrentlyInstalled    //if it's uninstalled, then the record should still exist

Wave/t fileList   //a list of the files included in the package.
Wave   fileType //bit set for 1= Igor Procedure, 2=XOP, 3=Help File

uint16 structVersion  //describes this structure
Endstructure
I would suggest to convert packageVersion to a struct like
Structure packageVersion
uint32 main
uint32 minor
string patchlevel
EndStructure

so it is flexible and easy to use. E.g. patchlevel is nice if you are doing releases from your version control system.

I don't understand your remark for the md5hash string, but maybe we should use SHA1 instead.

February 7, 2011 at 07:46 am - Permalink

I would like that a framework would also include what I've started with PackageTools. The top level information for a given procedure file consists of the following (with LinkVS as an example):

Static StrConstant thePackage="LinkVS"
Static StrConstant thePackageFolder="root:Packages:LinkVS"
Static StrConstant theProcedureFile = "LinkVS.ipf"
Static StrConstant thePackageInfo = "A control panel to use the LinkDisplay functions"
Static StrConstant thePackageAuthor = "Jeffrey J Weimer"
Static Constant hasHelp = 1
Static Constant thePackageVersion = 1.5
Static Constant removable = 1


I have considered whether to convert this to be in an initialization structure rather than top-level strings. Recommendations would be appreciated.

I would suggest parameters sourceURL and versioncheckURL that will denote locations of the package code and place to check for recent version, respectively.

Where are you proposing this structure is to be resident -- within each procedure file (or top level procedure file), or alternatively in a central location for each user (ie, /.../WaveMetrics/Igor Pro Package Receipts)?

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

February 7, 2011 at 10:50 am - Permalink

As to versions ... I would actually suggest against the breakout in major, minor, and patch. Two reasons -- simplicity and duplication. While I can understand where the details have there merits, how often will a basic user/developer (ie, most folks) really be doing patch level development and posting? Even I would rather just write 1.50 or 1.51 for my "package" updates rather than having to do a 1 and a 50 or 51 and a 0. As to the subversion aspects that control patch level releases, you can pull an equivalent of "patch level" using a proper $Revision: $ tag at the top of a procedure file and a FetchURL command to that file on IgorExchange.

--
J. J. Weimer
Chemistry / Chemical & Materials Engineering, UAHuntsville

February 7, 2011 at 10:56 am - Permalink

Forum

Support

Gallery

Igor Pro 9

Learn More

Igor XOP Toolkit

Learn More

Igor NIDAQ Tools MX

Learn More