Hello,

I have attached the code to this email. 
How to install it:
  - Take an image where MC and Omnibrowser are installed.
  - Load Package.cs
  - Load PackageBootstrap.cs
  - To convert all the packages from packageinfo to package instance, execute 'Package bootstrap'.

The 12 tests contained in PackageTest should be green.

In the World/open menu, there is a new entry, 'package browser', open one. On the lest pane list, non indented name are packages, indented one are category contained in this package. I do not like this design, I thing we should get rid of categories, but we still would like to read old fashion packages...

Click on a package, for instance Omnibrowser. Click on the menu, you can add a new repository for this project, create a new package, save the system, ...

If you display a method menu, the first choice is 'Move To Another Package'.

It is far from behing finished... Any comment appreciated.

Alexandre


On Sun, Feb 13, 2005 at 09:21:10AM +0100, stéphane ducasse wrote:
> >I agree to a large extent.  At least the simple stuff that PackageInfo 
> >knows how to do on its own -- show the code it contains, show its 
> >name, show its comment, be able to unload itself -- ought to be doable 
> >in a Package Browser tool completely separate from SqueakMap.  (A 
> >Package Browser would list the PackageInfos comprising all of the code 
> >in the image.)
> 
> By the way alex will certainly release some code to support for a real 
> package class and this will be a good start to have a better support 
> for MC. Mike was doing the same so we are trying to merge effort.
> The idea is that we can then avoid to have category but first class 
> objects instead.
> Alex can we have initialization with your approach? I guess yes but not 
> as method of a subclass so may be this would be a nice idea to have a 
> package been a subclass of Package.
> 
> The last time I wanted to use Yaxo but I could not know whether the XML 
> parser was part of it or another package. So what I ended up doing was 
> to load the package Yaxo and check whether classes changed. So this is 
> to avoid this situation that we should have meta-information.
> 
> >I kind of think of SqueakMap as the interface to the outside world of 
> >packages.  Some of the meta-data associated with packages is mostly 
> >"outside world" related, such as the URL, whether it's "published", 
> >which SM version it is... these are probably not as essential for a 
> >simple in-image PackageInfo, so they could stay in SMPackage.  
> >"Author" is kind of a borderline case... method timestamps in the 
> >image have author initials, although classes in the image don't keep 
> >track of their authors.  I guess I'm okay with most metadata being in 
> >SMPackage for now.
> >
> >>(snip)
> >>
> >>So, my proposal is:
> >>
> >>	1. Move ahead with PackageInfo.
> >
> >Yes.
> >
> >>	2. Add some minor descriptive info to PackageInfo, like 
> >>"description",
> >>and maybe a url for more info.  It would be great for these to be 
> >>there.
> >> The description should be a Text, ideally, just like class comments.
> >
> >I think adding a single comment/description instvar is a good idea.  
> >Mmm, a url seems like something relating to the outside world which 
> >could be handled by the corresponding SMPackage instance.
> >
> >>	3. Add some sort of variable, which optionally refers to a SqueakMap
> >>package corresponding to that PackageInfo.  I defer to Goran for what
> >>kind of info should go there, but the idea is, so long as the tools 
> >>know
> >>which PackageInfo goes with which SqueakMap package, the tools can do
> >>all the same smart things they could do if PackageInfo were the *same*
> >>as a SqueakMap package.
> >
> >I think the SMPackage actually points to the PackageInfo instance 
> >right now (if it's a PI-based SMPackage).  So, mm, I think every 
> >PackageInfo should be able to look up its corresponding SMPackage.  
> >Goran can confirm.  Maybe that needs  a bit of thought as to how they 
> >will be looked up.
> >
> >Just so it's clear, I think the situation would be this:
> >
> >The partitioned image would have a global list of PackageInfo 
> >instances.  These PI instances (with names like 'Morphic', 'Graphics', 
> >etc) would define ALL of the source code in the image.  Also, every 
> >method in the Basic image would belong to ONE package.  (I don't think 
> >there'd be any reason to use PI method overrides within the Basic 
> >image, at least.)
> 
> It depends because may be you will face cases where a method has in 
> fact two behavior and one part depends on the presence of another 
> package.
> 
> >(Mm, the browsers will probably still let you create a new class 
> >category without a new PI instance, so you'd have code outside of any 
> >package... that would need to be tightened up.)
> 
> This should not. Else this will be the mess.
> 
> >If you had SqueakMap installed (which you would in a Basic image), 
> >that would have its list of SMPackage instances, which would contain 
> >the SMPackages pointing to the above PackageInfo instances, plus 
> >possibly a mishmash of other SMPackages (changesets, projects, etc) 
> >which happened to be loaded but which are not PI-related packages.
> 
> I do not understand why you need SM to have a list of packages inside 
> the image. You should have all the categories as packages and they may 
> or not be saved as SM packages.
> 
> I think that if you want to partition the image and you start to want 
> to support sar, changeset, ... as packages you will die. Why not take 
> the simple idea that a category is a package as in MC?
> 
> >Is there a situation where you'd have the global list of PI instances 
> >in a more minimal image, but not have SqueakMap installed?  Could be, 
> >but that might be uncommon.  I was thinking that the Minimal image 
> >would still have the PI instances, which means PackageInfo would need 
> >to be part of the Kernel, but I don't know if that's necessary.  As 
> >long as it can add code to itself.  (That is when we take a serious 
> >look at Spoon. :) )
> >
> >>Everyone seems to agree with #1.  #2 is contentious, so consider this
> >>email to be my 2 cents on the issue.  #3 is a possible compromise for
> >>everyone who cares about #2.
> >
> >I think #2 is not that contentious, if we just add a "comment" or 
> >"description" instvar.  If we do that, should we call it "comment"?
> 
> Why not going for a real class.
> Alex can you publish your code?
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.iam.unibe.ch/~bergel
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Package.16.cs.gz
Type: application/x-gunzip
Size: 9322 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050214/c3dc8c3b/Package.16.cs.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PackageBootstrap.1.cs.gz
Type: application/x-gunzip
Size: 510 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050214/c3dc8c3b/PackageBootstrap.1.cs.bin