[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
>
Re: Package system, Paul Kienzle, 2005/10/22