Development of an IGOR installer/package manager

Another Option

If I understand, you are proposing the installer search for the files by parsing the manifest to the package.

I would rather that any installer work on the predicate that all files needed for the installation or update are within the package, and the package is downloaded in its entirety local to the machine. The package is then expanded locally and subsequently the files are moved/copied to their proper locations after deleting/removing any older versions. This does not take away from asking that packages have manifests, and your example is a good start.

In the example below, I show what I had in mind for an XML script (for an update of a package rather than an installation). This would be found by the installer within the top level of the package archive. I also prefer elements to properties in doing XML.

<br />

<?xml version="1.0"?><br />

<package><br />

<description><br />

    <name>SLIM</name><br />

    <version>1.1</version><br />

    <author>J J Weimer</version><br />

    <date>March 18, 2009</date><br />

</description><br />

<requirements><br />

     <IgorVersion>6.10</IgorVersion><br />

     <platform /><br />

</requirements><br />

<installation /><br />

<update><br />

     <remove><br />

         <UserProcedures>Slim Folder:Graphs Folder</UserProcedures><br />

         <UserProcedures>Slim Folder:Notebooks Folder:notebooksetup.ipf</UserProcedures><br />

         <UserProcedures>Slim Folder:Notebooks Folder:notebooklayout.ipf</UserProcedures><br />

     </remove><br />

     <install><br />

         <UserProcedures>Slim Folder:Graphs Folder</UserProcedures><br />

         <UserProcedures>Slim Folder:Notebooks Folder:donotebook.ipf</UserProcedures><br />

     </install><br />

</update><br />

</package><br />

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

Log in or register to post comments

March 18, 2009 at 03:50 pm - Permalink

andyfaff

The suggestion I had was that all the files are copied - lock, stock and two smoking barrels into the install directory. However, only files/folders that need shortcuts to IGOR extensions or IGOR procedures need to be mentioned in the manifest.

The keypoint with development of an installer is that dependencies can be installed at the same time. There are already open source installer programs that work for OSX and Win32, and they work well for a single package for no dependencies. However, whenever a package requires another package everything starts to fall apart. Either the user can download and install the package themselves, making more work (and possibly getting it wrong), or the installer can include it. THe problem with either of those is that you end up with multiple versions in different places, which can cause problems.

Log in or register to post comments

March 18, 2009 at 09:21 pm - Permalink

aclight

I would prefer that the installer/package manager be able to download packages from some centralized repository (though the possibility to allow the user to download them manually is probably also necessary).

One thing to keep in mind with regards to downloading packages is that if Igor starts to become internet aware and especially if it can download packages from the internet I think security needs to be kept in mind. For example most Linux package repositories use SSL to get packages and packages are cryptographically signed and such.

Log in or register to post comments

March 19, 2009 at 06:41 am - Permalink

jjweimer

It seems then, the installer will have a set of steps to run ....

1) get the package (download entire archive from repository)
2) parse the script for "dependencies"
3) confirm the dependencies
--> if (exist and proper version): no action
--> if (absent or improper version): note for subsequent download
4) parse the script for "actions"
5) run actions
--> delete outdated files/folders
--> install updated files/folders
6) repeat from step 1 for each dependency

I would propose that actions be either remove or install within defined folder locations. Following on this for the XML ...

<br />

<?xml version="1.0"?><br />

<package><br />

<description><br />

    <name>SLIM</name><br />

    <version>1.2</version><br />

    <author>Igor Exchange Installer Group</author><br />

    <date>March 19, 2009</date><br />

</description><br />

<requirements><br />

    <IgorVersion>6.10</IgorVersion><br />

    <platform /><br />

</requirements><br />

<dependencies><br />

    <dependency><br />

       <name>SOCKIT</name><br />

       <URL>http://www.igorexchange.com/project_download/files/projects/SOCKIT-IGOR…</URL><br />

        <version>1</version><br />

    </dependency><br />

    <dependency><br />

         <name>easyHTTP</name><br />

         <version>1</version><br />

         <URL>http://www.igorexchange.com/project_download/files/projects/easyHttp-IG…</URL><br />

        <version>1</version><br />

     </dependency><br />

     <dependency><br />

        <name>ZIP</name><br />

        <version>1</version><br />

        <URL>http://www.igorexchange.com/project_download/files/projects/ZIP-IGOR.5…</URL><br />

     </dependency><br />

     <dependency><br />

        <name>XMLutilis</name><br />

        <version>1</version><br />

        <URL>http://www.igorexchange.com/project_download/files/projects/XMLutils-IG…</URL><br />

     </dependency><br />

</dependencies><br />

<actions><br />

    <Examples /><br />

    <IDFLProcedures /><br />

    <IgorExtensions><br />

        <remove>SLIM</remove><br />

        <install>SLIM</install><br />

    </IgorExtensions><br />

    <IgorHelpFiles /><br />

    <IgorProcedures /><br />

    <LearningAids /><br />

    <Manual /><br />

    <Miscellaneous /><br />

    <MoreExtensions /><br />

    <MoreHelpFiles /><br />

    <ProductDemos /><br />

    <TechnicalNotes /><br />

    <UserProcedures><br />

        <remove>SLIM.ipf</remove><br />

        <install>SLIM.ipf</install><br />

    </UserProcedures><br />

    <WaveMetricsProcedures /><br />

</actions> <br />

</package><br />

The package contents for this would be ...

<br />

root (folder)<br />

  -- manifest.xml<br />

  -- AboutMe.txt<br />

  -- IgorExtensions (folder)<br />

    -- Windows (folder)<br />

    ----- SLIM (folder)<br />

    -- Macintosh (folder)<br />

    ----- SLIM (folder)<br />

  -- UserProcedures (folder)<br />

    -- Both (folder)<br />

    ----- Slim.ipf (file)<br />

Finally, it might be appropriate for the installer to create a new sub-folder to store its records. For example, in the new user accessible directory structure of Igor 6.1, create a folder called Igor Installer Frameworks with sub-folders for each package wherein are stored the most recent copies of the installer manifest and the installer log.

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

Log in or register to post comments

March 19, 2009 at 09:40 am - Permalink

andyfaff

R.E. secure transfer with easyHttp

easyHttp can do https and sftp, which presumably uses SSL. easyHttp is linked against the OpenSSL library on Win32 and OS X. I think that that should be secure enough.
I agree with the signing of a package - it shouldn't be too hard to write an md5 hash generator for a string/file (not sure stringcrc is enough), which is distributed with a package. An installer could download the hash from the website, then download the package and check the hash.

I'm also investigating SSL connections for SOCKIT.

Log in or register to post comments

March 19, 2009 at 08:23 pm - Permalink

aclight

Actually, I think sftp (and scp) both typically use SSH, not SSL (see http://en.wikipedia.org/wiki/SSH_file_transfer_protocol).

As for signing, I think that typically package managers use GPG signed packages, not just md5 hashes. I couldn't find a good source for this, but see http://fedoranews.org/tchung/gpg/ for example. I believe the benefit is that with md5, if the source of the downloaded package and downloaded md5 hash of that package (say, for example, www.igorexchange.com) was to be compromised, a hacker could easily provide the correct md5 for the hacked packages and then users would have no idea that they were installing hacked packages since the md5 hashes would match. On the other hand, with GPG signed packages, the hacker would need the private key of the signer to re-sign a hacked package, and that is much less likely to happen. Signed packages involve quite a lot more work on both the repository and end-user sides, but my understanding is that they are much more secure. Whether that security is necessary in this situation is debatable, but something to keep in mind during design time.

Log in or register to post comments

March 20, 2009 at 07:06 am - Permalink

Development of an IGOR installer/package manager

Igor Pro 9

Igor XOP Toolkit

Igor NIDAQ Tools MX