splitting MC packages

Is there a clear doc somewhere about how to deal with MC packages that
have a common prefix ?

e.g. I currently have Coral

I want a separate Coral-Examples, and from how MC behaves I have the
feeling it's not possible…
When do we switch to git already ?

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

This has nothing to do with MC, but with how PackageInfo defines what
belongs in a package. 5 years ago one could override PackageInfo in a
package to define different rules, so you could have easy defined a
different split. Unfortunately this is no longer possible due to
hardcoded PackageInfo semantics everywhere.

The only solution is to stick with consistent and well though package
name scheme. Not the only possible naming strategy, but the one we
developed for Seaside works pretty well:
http://code.google.com/p/seaside/wiki/PackageNaming

Lukas

On 12 August 2011 22:14, Damien Pollet <[hidden email]> wrote:


--
Lukas Renggli
www.lukas-renggli.ch

On 12 August 2011 22:21, Lukas Renggli <[hidden email]> wrote:
> The only solution is to stick with consistent and well though package
> name scheme. Not the only possible naming strategy, but the one we
> developed for Seaside works pretty well:
> http://code.google.com/p/seaside/wiki/PackageNaming

I know about these conventions, but how do I proceed towards them? :)

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

Maybe I have no clue about your problem, or maybe I am in complete ignorance and denial about my own problems :)

With that caveat, here is what I *think* has been working for me.  To illustrate it, let's rewind to when Pharo was just getting started and I was just starting to move away from Windows.  In my Dolphin image are packages with names like HPViridia and DatexCapnomac.  The names match physiologic monitors, but that's not really important.  What is important is that once I got a handle on PackageInfo, I started naming things like this as

  Recordkeeper-monitors-DatexCapnomac
  Recordkeeper-monitors-HPViridia

Saving the one package called Recordkeeper then captures all of the infrastructure, device interfaces, and GUI (the latter being largely vapor right now).  There are 28 sub-packages.  Once you create a new sub-package, you can do things like

   aClass withAllSubclasses do:[ :each | each category:'ThisAndThat-NewSubpackage' ].

to move things to it.

Two other packages, Studies and Hardware, have growing lists of sub-packages.  AFAIK, package names are case-sensitive, with one exception: loose methods.  PackageInfo abuses method categories to package these methods.  Anything like *Recordkeeper-monitors-DatexCapnomac will include methods in the named package.  I doubt it will work if there are two package names differing only by case, so it can be confusing.

What I do is scan my image for methods that I wrote and have not claimed ownership of the containing package.  Looking at the extension methods in the MC browser is one way to do that; I have code in Migrate that has saved me from myself on several occasions.

HTH.

Bill


________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Damien Pollet [[hidden email]]
Sent: Friday, August 12, 2011 5:32 PM
To: [hidden email]
Subject: Re: [Pharo-project] splitting MC packages

On 12 August 2011 22:21, Lukas Renggli <[hidden email]> wrote:
> The only solution is to stick with consistent and well though package
> name scheme. Not the only possible naming strategy, but the one we
> developed for Seaside works pretty well:
> http://code.google.com/p/seaside/wiki/PackageNaming

I know about these conventions, but how do I proceed towards them? :)

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet

On 12 August 2011 23:32, Damien Pollet <[hidden email]> wrote:
> On 12 August 2011 22:21, Lukas Renggli <[hidden email]> wrote:
>> The only solution is to stick with consistent and well though package
>> name scheme. Not the only possible naming strategy, but the one we
>> developed for Seaside works pretty well:
>> http://code.google.com/p/seaside/wiki/PackageNaming
>
> I know about these conventions, but how do I proceed towards them? :)

Closing the eyes and restarting from scratch. We did that too with the
Seaside packages at some point.

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

On 13 Aug 2011, at 09:06, Lukas Renggli wrote:

We did the same for Moose. We kind of followed this process:
1. create new sub-package XYZ-Sub*
2. move classes from XYZ to XYZ-Sub*
3. repeat until all classes and extensions from XYZ are moved away to subpackages
4. add the Monticello repository to XYZ-Sub*
5. commit all XYZ-Sub* packages. Make sure that there are no categories without packages left behind (in other words to not lose code)
6. save the image
7. load in a fresh image
8. if problems appear, and they always appear because it is manual work, go to the previous image and recommit


A useful script for renaming a package that ensures also that extensions get renamed:

renamePackage: oldPackageName to: newPackageName
        "self renamePackage: 'Seaside-Squeak-Development-Core' to: 'Seaside-Pharo-Development-Core'"
       
        | oldPackage newPackage oldWorkingCopy newWorkingCopy |
        oldPackage := PackageInfo named: oldPackageName.
        newPackage := PackageInfo named: newPackageName.
       
        " rename system categories "
        oldPackage systemCategories do: [ :oldCategory |
                | newCategory |
                newCategory := oldCategory allButFirst: oldPackage systemCategoryPrefix size.
                Smalltalk organization renameCategory: oldCategory toBe: newPackage
systemCategoryPrefix , newCategory ].
       
        " rename method categories "
        oldPackage extensionClasses do: [ :extensionClass |
                (oldPackage extensionCategoriesForClass: extensionClass) do: [ :oldProtocol |
                        | newProtocol |
                        newProtocol := oldProtocol allButFirst: oldPackage methodCategoryPrefix size.
                        extensionClass organization renameCategory: oldProtocol toBe:
newPackage methodCategoryPrefix , newProtocol ] ].
       
        " update monticello packages "
        oldWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: oldPackageName).
        newWorkingCopy := MCWorkingCopy forPackage: (MCPackage named: newPackageName).
        newWorkingCopy repositoryGroup: oldWorkingCopy repositoryGroup; modified: true.
       
        " test is all methos have been caught "
        oldPackage methods isEmpty
                ifTrue: [ oldWorkingCopy unload. PackageOrganizer default
unregisterPackage: oldPackage ]
                ifFalse: [ self error: 'Some code entities remain in the old
package, please migrate manually.' ]

Cheers,
Doru


> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>

--
www.tudorgirba.com

"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."

On 13 August 2011 09:42, Tudor Girba <[hidden email]> wrote:
> A useful script for renaming a package that ensures also that extensions get renamed:

argh, and you send me this just after I did the whole thing by hand :)

--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet