I'm not sure I understand what you expect Goran to add - load scripts are there. People can write load scripts, right now, that first load SAR, and then load their favorite package.
Anyone can do this, even for packages he just uses.
I think it's important to let Goran finish his refactoring adding versions without distraction, because that is the basis for letting anyone create configuration. And nobody else can do that.
Daniel
Doug Way dway@riskmetrics.com wrote:
On Friday, November 29, 2002, at 11:55 AM, Julian Fitzell wrote:
goran.hultgren@bluefish.se wrote:
Julian Fitzell julian@beta4.com wrote:
Or just get dependencies working and then the package can depend on the SARInstaller, and the SARInstaller will get installed automatically, first.
Working on it! Did a whole lot of work yesterday evening etc. But... This is actually *not* a dependency. SqueakMap works fine without SARInstaller. :-)
I didn't say SqueakMap depended on SARInstaller. I meant that packages that are packaged as SARs depend on SARInstaller. So when you try to install a SAR package and don't have SARInstaller, it will get installed first since it is a dependency.
Right, that might be a good way to handle it once the dependency stuff is in place.
However, I'm guessing it will be a while before the dependency stuff is working, so in the meantime, I agree that it would be good to simply install the SARInstaller as part of the SqueakMap install. (Which I guess would be done with a load script as Goran described.)
There are a number of packages on SqueakMap now which expect SAR to be available, such as Roel's, and people are starting to submit [BUG] reports about this problem (see Ross Boylan's message), so perhaps Goran will be able to add this soon. :-)
- Doug Way
On Saturday, November 30, 2002, at 04:36 AM, Daniel Vainsencher wrote:
I'm not sure I understand what you expect Goran to add - load scripts are there. People can write load scripts, right now, that first load SAR, and then load their favorite package.
Anyone can do this, even for packages he just uses.
True. But I thought that in Goran's earlier message he said that he might add a load script to replace the "SqueakMap" package so that it loaded a separate "SqueakMap base" package and then also SARInstaller. Which would mean that SAR is always installed with the SqueakMap bootstrap (at least until configurations are supported).
I think that would be simpler than requiring all package owners who use the SAR format to have a special load script to install SARInstaller, since SAR is emerging as a somewhat standard way to handle multi-file installs. (Assuming it's relatively simple for Goran to add this. If not, then let's not worry about it... this is only an issue until configurations are supported.)
I think it's important to let Goran finish his refactoring adding versions without distraction, because that is the basis for letting anyone create configuration. And nobody else can do that.
Agreed.
- Doug Way
Daniel
Doug Way dway@riskmetrics.com wrote:
On Friday, November 29, 2002, at 11:55 AM, Julian Fitzell wrote:
I didn't say SqueakMap depended on SARInstaller. I meant that packages that are packaged as SARs depend on SARInstaller. So when you try to install a SAR package and don't have SARInstaller, it will get installed first since it is a dependency.
Right, that might be a good way to handle it once the dependency stuff is in place.
However, I'm guessing it will be a while before the dependency stuff is working, so in the meantime, I agree that it would be good to simply install the SARInstaller as part of the SqueakMap install. (Which I guess would be done with a load script as Goran described.)
There are a number of packages on SqueakMap now which expect SAR to be available, such as Roel's, and people are starting to submit [BUG] reports about this problem (see Ross Boylan's message), so perhaps Goran will be able to add this soon. :-)
- Doug Way
On Saturday 30 November 2002 09:26 am, Doug Way wrote:
I think that would be simpler than requiring all package owners who use the SAR format to have a special load script to install SARInstaller
The problem with this is back to the "self-installing archive" problem: we'd then need to put that script in the front of the SAR, and it would have to crawl up the stack contexts to find the stream, etc.
I think a better strategy would be just to notify the user when no installer is available. Which would go along with the "better error reporting" that we want for SM loading in general.
Ned Konz ned@bike-nomad.com wrote:
On Saturday 30 November 2002 09:26 am, Doug Way wrote:
I think that would be simpler than requiring all package owners who use the SAR format to have a special load script to install SARInstaller
The problem with this is back to the "self-installing archive" problem: we'd then need to put that script in the front of the SAR, and it would have to crawl up the stack contexts to find the stream, etc.
I think a better strategy would be just to notify the user when no installer is available. Which would go along with the "better error reporting" that we want for SM loading in general.
I think that these two steps are good to do (will find time for it tomorrow):
1. Get 1.05 out with the small amount of current buglets fixed. And if Ned has improvements to the current "installation scheme" and its more or less nonexistent error feedback to the user then I gladly receive changesets ASAP. :-)
2. At the same time rename "SqueakMap" to "SqueakMap base" and post a load script called "SqueakMap" and let that install the good-to-have installers like SAR.
Hopefully this will give us a somewhat working SM until I get my 1.1 out. The other day I hacked a lot on it and refactored like crazy. It is moving along fine but it will take some time...
Btw - if someone could help me out with writing some more on minnow about howto make a package etc, it would really help. I would of course help out reading it through etc!
regards, Göran
squeak-dev@lists.squeakfoundation.org
-
Daniel Vainsencher -
Doug Way -
goran.hultgren＠bluefish.se -
Ned Konz