> 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?