Hello Chris

I read your answer and found out that to come from MCWorkingCopy to
PackageInfo I need to do the following

MCWorkingCopy
"is a subclass of MCPackageManager"

MCWorkingCopy allManagers collect: #package.
"gives an array of MCPackage"

MCPackage>>packageInfo
gives a PackageInfo instance

Here comes my follow-up question?
How do I get from a PackageInfo instance to the MCWorkingCopy instance?
I do get a PackageInfo instance for example with
    PackageInfo named: 'MyPackage'

If we can do this we can get to the version info and display it in the
browser we get with
    PackageList open


--Hannes



On 9/8/10, Chris Muller <ma.chris.m at gmail.com> wrote:
> 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
>>>>>
>>>>
>>>>
>>>
>>
>