I wrote:

> Personally, what I like about PackageInfo is that it is very open and
> lightweight.

.. AND, that it is already part of core Squeak, and SCM tool agnostic...


> On Wed, Sep 8, 2010 at 6:10 AM, Hannes Hirzel <hannes.hirzel at gmail.com> wrote:
>> Chris, could you please elaborate with code snippets how you have been
>> creating PackageInfo subclasses?
>>
>>
>> I assume you added some instance variables in the subclasses.
>>
>> BTW the instance variables of PackageInfo are not commented. What are they for?
>>
>> I have opened a ticket for
>>    PackageInfo class comment
>>
>> http://bugs.squeak.org/view.php?id=7562
>>
>> where I put some of the discussion here.
>>
>> The goal is to have some instructions how to use PackageInfo.
>>
>> --Hannes
>>
>>
>> On 9/6/10, Chris Muller <asqueaker at gmail.com> wrote:
>>> I have been creating PackageInfo subclasses for years for all of my
>>> packages.  I really like storing meta information about packages
>>> within the package itself and I recommend that others do this too,
>>> because it allows the system more easily reflect on itself.
>>>
>>> I use PackageInfo subclasses to sort packages in load-dependent order
>>> and to easily create SAR files with "one-click."  (See MaSarPackage,
>>> on SqueakMap).
>>>
>>> MaSarPackage includes an extension to PackageInfo that allows proper
>>> registration of a PackageInfo subclass, but to default to a superclass
>>> instance if non-existent.  I think we should consider adopting this
>>> into the trunk so that any package that wants to can declare its own
>>> meta information and have it be saved in with the MC package.
>>>
>>>  - Chris
>>>
>>> On Fri, Sep 3, 2010 at 5:08 PM, Bernhard Pieber <bernhard at pieber.com> wrote:
>>>> Am 03.09.2010 um 19:59 schrieb Ralph Johnson:
>>>>> On 9/3/10, Bert Freudenberg <bert at freudenbergs.de> wrote:
>>>>>> A package is a (sub-) instance of PackageInfo. Packages are held by
>>>>>> PackageOrganizer.
>>>>>>
>>>>>> One idea would be to include a PackageInfo subclass in each package, and
>>>>>> its class comment or methods would describe the package. That would hook
>>>>>> into HelpSystem so one could browse comments, instructions, examples
>>>>>> etc. per package.
>>>>>>
>>>>>> There are a few conventions for that already, e.g. the class name should
>>>>>> end in "Info" and it should be in a category named "PackageName-Info".
>>>>> We could certainly include a PackageInfo subclass in a package.  But
>>>>> Monticello wouldn't use it to make the instance of the package, would
>>>>> it?
>>>> The strange thing is that PackageInfo supported subclasses from day one.
>>>> According to Avi they were even required at first. However, I looked but
>>>> could not find a place in the code where they are instantiated. It seems
>>>> that one has to manually register them by code in order to use them. It
>>>> seems that no PackageInfo subclasses can be created by just using the
>>>> tools. :-/
>>>>
>>>> - Bernhard
>>>>
>>>
>>>
>>
>