octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Package system


From: Søren Hauberg
Subject: Re: Package system
Date: Fri, 21 Oct 2005 21:58:21 +0200

Hi, 

fre, 21 10 2005 kl. 13:18 -0400, skrev John W. Eaton:
> On 21-Oct-2005, Soren Hauberg wrote:
> 
> | I just updated the code to include some documentation. You can get it
> | from http://hauberg.org/octave-package/package-0.2.1.tgz
> 
> This looks good so far.  Thanks for working on it.
> 
> I have a few comments:
> 
>   * I recently modified rmdir to accept an optional second argument
>     ("s") which if present tells rmdir to work recursively (this
>     choice was for compatibility; I guess the "s" means
>     "subdirectories too"), so we shouldn't need the rm_rf.m file.
Okay. I'm using 2.9.3 and would prefer not working on CVS version as a have 
to do "real work" too. I'm guessing CVS is too unstable for that, right?

>   * We probably need something different from the issuperuser
>     function, which checks to see if the environment variable USER has
>     a value of "root".  That's probably not a good test.  It's likely
>     to fail on Windows systems (Cygwin or MinGW).  Even on Unixy
>     systems it would miss the case of an additional user name with a
>     UID of 0.
> 
>     Checking for root is maybe not the right thing anyway.  We just
>     want to know whether we can install files in Octave's site
>     directory.  That's a function of more than just being root.  Maybe
>     we should do something like
> 
>       use_system_dir = false;
>       fs = stat (system_dir);
>       if (S_ISDIR (fs.mode))
>         ## Directory exists.  Can we create a file there?
>         tfile = strcat (system_dir, filesep, "foo");
>         fid = fopen (tfile, "w");
>         if (fid > 0)
>           ## We can write files in existing directory, so we should be
>           ## able to use it.
>           use_system_dir = true;
>           fid = fclose (tfile);
>           unlink (tfile);
>         endif
>       else if (mkdir (system_dir))
>         ## Directory did not exist, but we were able to create it, so
>         ## we should be able to use it.
>         use_system_dir = true;
>       endif
> 
>     (This code will only work with recent CVS Octave due to changes in
>     the way mkdir works and the use of S_ISDIR.)
As above.

>   * We should make the untar function compatible with Matlab's untar
>     function and include it with Octave.  (Maybe implement the tar,
>     zip, unzip, gzip, and gunzip functions at the same time.)
I'd be happy to this (writing untar was dead easy), but I just have two 
questions:
1) Could we change split to return a cell array instead of an array?
This would IMHO be a good thing anyway, and would make untar work
without a lot of hassle. There's a patch for this somewhere on the bugs
list.
2) Is the approach taking in untar acceptable? It's basicly just a
system call, but that's not going to be portable (I'm thinking about
windows here).

>   * The remaining functions currently have the following names
> 
>       installed_packages.m
>       load_packages.m
>       uninstall.m
>       get_unsatisfied_deps.m
>       install.m
> 
>     Maybe we should have just one command?
> 
>       pkg -list
>       pkg -install -nodeps pkg-name ...
>       pkg -uninstall nodeps pkg-name ...
>       pkg -require pkg-name ...
> 
>     or multiple names, but all starting with pkg:
> 
>       pkg_list
>       pkg_install
>       pkg_uninstall
>       pkg_require (or pkg_load)
> 
>     If the get_unsatisfied_deps is not intended to be called by
>     users, then it should have a name like __pkg_uninstalled_deps__.
I have just changed the syntax to one function called pkg that accepts 
-install, -uninstall, etc, as you described. Then get_unsatisfied_deps 
can become a function inside the pkg file.

/Soren

> Thanks,
> 
> jwe
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]