Information for a package manager to retain.

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

thomas_braun

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

jjweimer

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

jjweimer

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

Information for a package manager to retain.

Igor Pro 9

Igor XOP Toolkit

Igor NIDAQ Tools MX