[Pharo-project] 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 <damien.pollet@gmail.com> wrote:
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
-- Lukas Renggli www.lukas-renggli.ch
On 12 August 2011 22:21, Lukas Renggli <renggli@gmail.com> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Damien Pollet [damien.pollet@gmail.com] Sent: Friday, August 12, 2011 5:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] splitting MC packages On 12 August 2011 22:21, Lukas Renggli <renggli@gmail.com> 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 <damien.pollet@gmail.com> wrote:
On 12 August 2011 22:21, Lukas Renggli <renggli@gmail.com> 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:
On 12 August 2011 23:32, Damien Pollet <damien.pollet@gmail.com> wrote:
On 12 August 2011 22:21, Lukas Renggli <renggli@gmail.com> 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.
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 <tudor@tudorgirba.com> 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
participants (4)
-
Damien Pollet -
Lukas Renggli -
Schwab,Wilhelm K -
Tudor Girba