PackageInfo subclasses do not add any extra inst-vars, and they
shouldn't because the primary method of persistence, Monticello, does
not persist objects, only code.  That code can be run at various times
to assist with configuration.  They only override certain methods that
declare the structure and contents of the package.

Creating a PackageInfo subclass is no different than creating a
subclass of any other class:

PackageInfo subclass: #MyPackageInfo
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'MyPackage-Info'

For example, if a package requires several system changes (like
Stephane Rollandin's muO), then one could override #patchNames to,
instead of answering an empty Array, answer an Array of strings which
are the names of the change-set files, in order, that should be loaded
to make a running muO system.

Similarly, the MyPackageInfo subclass can also report its *immediate*
dependencies in terms of other packages by overriding
#prerequisitePackageNames:

prerequisitePackageNames
	^ super prerequisitePackageNames ,
		{ MyPrerequisitePackageInfo packageName.
		MyOtherPrerequisitePackageInfo packageName }

Even by only declaring immediate dependencies of each package, the
full dependency tree can then be calculated in load-dependent order by
the computer..

Personally, what I like about PackageInfo is that it is very open and
lightweight.  *I* added the notion of #prerequisitePackageNames to
handle the dependencies myself.  But if this is of general interest we
should fold it into the trunk.

This and more documentation is available on the wiki:

    http://wiki.squeak.org/squeak/3329
    http://wiki.squeak.org/squeak/6155

 - Chris


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