Re: [Help-smalltalk] [RFC] handle paths in a saner way

[Paolo Bonzini]

> I don't create new images - I always copy the image file. Is that a bad
> idea?

No, absolutely.  But the .stpre or .st/pre.st file is a good place to 
put bug fixes in, for example.

Another thing to put in the file could be this:

(FileStream open: Directory image, '/pre.st' mode: 'r' ifFail: [ ^self ])
    fileIn

which is a little dangerous to do by default, but could be useful to a 
user that wants to load different packages in different default images 
(so he will put a "fileInPackages:" in the image directory's pre.st file).

It must be said also that working with environment variables is kind of 
verbose/uncommon.  Using something like --image-directory would be simpler.

> > - Smalltalk programs have access to the aforementioned `~/.st' directory
> > as `Directory userKernel' (name subject to change).  A `packages.xml'
> > file can be put in the directory too -- I like this a lot.
>
> I'm not sure if I've said this before, but I'm greatly in favour of
> having a search path for package files. The user (well, me, anyway) is
> likely to have packages that fall into a number of categories. In
> particular, packages that they have written themselves and unstable
> versions of those packages.

Well, for this, remember that a `packages.xml' file can be put in the 
image directory too, and source files will only be sought relative to 
that directory.

One could have, then, aliases such as

  alias gstdev=gst --image-dir=$HOME/gst-devel

This would:

1) rebuild the image when you modified "global" stuff in ~/.st (as I 
said before, with bugfixes etc.)

2) allow you to use package descriptions from $HOME/gst-devel/packages.xml


In general, however, I agree that it would be best to have source and 
package description in the same file, possibly a ZIP file like Java's 
JARs.  Note that in this case the `packages.xml' file would not die, it 
would just be in the ZIP file.

> Also, why XML, when we don't even have an XML parser in the standard
> libraries? (OK, I know I've said that before).

Just because.  XML is easily extensible (remember when we added 
<namespace> to packages.xml) and any other syntax would not be much 
easier to parse (e.g. JSON).

The obvious exception may be Smalltalk code, but in the case of ZIP 
files I mentioned above, one may not want to evaluate user code lightly 
if they care about security.

> > - if you don't like the semantics (details are in the manual, in the
> > Startup Sequence node), suggestions on how to improve them;
>
> I have read through this (I had never noticed it before!). It suggests
> that the image is rebuilt if it is older than any of the kernel files. I
> presume that doesn't happen if -I is given, but it doesn't say that.

I think it says that in the -I option description.  I should say "this 
section does not apply if -I is used".

> Whilst kind of nice, I'm not too keen on the automatic building of the
> image in the first place. I'd rather manually rebuild it when I change
> the kernel source. Under what circumstances will you have a gst
> executable but no valid image?

As hinted above, this would happen if you put files in ~/.st/kernel for 
example.  Then gst would notice the new files and make a new image.

> Also, it takes time to check the kernel files, no?

Yes, but this is for the user's experimenting, not for deployment where 
anyway you'd use -I or even an executable image file (chmod +x).

> It's not clear what is done with .stpre, but I guess that "If the image
> lies in the current directory, or if at least a kernel file was found
> outside of the system default path, a user-dependant `.stpre'(1)" should
> end with "is also loaded".

Indeed.

> > - whether root (or any other user who can write to /usr/local/share)
> > should be forbidden from having a ~/.st directory;
>
> The implication is that the .stpre and .stinit of that user would be
> built into the new image that is written to /usr/local/share? That
> doesn't sound like a good idea, not least because #methodSourceString
> will be broken. However, I don't think that that means they shouldn't be
> able to have local packages in ~/.st.

I've now added a --no-user-files option that is used during the build.

> > - whether `~/.st/init.st' makes sense at all; I'm inclined to remove it;
>
> I don't think it makes sense.

Yes.  Though the problems it has are mitigated by the --no-user-files 
option, and the code to support it is just a handful of lines.

Thanks for the suggestions!

Paolo