Thanks doru. I will digest that. I have the impression that I understand your approach but would not it be error prone to select the Rpackages you want to map to MCPackage?
Stef >>> Hi Stef, >>> >>> Thanks a lot for all this effort. >>> >>> I will reiterate again the original idea, which I still believe would work >>> best. >>> >>> RPackage is meant to become the organization entity in the image. MCPackage >>> will still be needed for versioning. Furthermore, for a while, categories >>> will still remain in the system for a while as an implementation detail. >>> RPackages mirror each category. >>> >>> The first step would be to keep loading from Monticello exactly like it is >>> now: it will create Categories, and this will mirror in RPackages. >> >> this sentence is not clear doru. >> Do you mean that a RPackage should contain classes that are contained in >> matching PackageInfo package? >> I mean >> RFoo >> contains RFoo and RFoo-zork categories classes? > > No. I meant we have a 1-1 mapping to categories. So, you will get multiple > RPackages in the system: RFoo, RFoo-zork ... > >>> The next step is to provide a tool that provides only a 1-1 mapping between >>> MC and RPackages that we can use for publishing. >> >> The problem is not publishing the problem is assigning classes to packages. > > I think that if we split loading and publishing logic as a transition phase > it would solve the problem, and I actually believe that you are talking about > a similar thing (see below). > >>> In this way, we would be able to: >>> - load existing MC without problems >>> - publish new MCPackages that will be compatible with other dialects >> >> let us see >> imagine the following scenaro >> >> PI-Foo contains >> Foo >> Foo-Zork >> >> => >> We get >> RFoo >> and RFoo-Zork >> >> we can save and people can load >> now >> >> I add a category Foo-Two >> in pharo I get an extra package >> we should modify metacelloConfig >> ok people can load it too >> >> in other system it will be in Foo >> ok we can load it >> >> >> Now if we should preserve the current loading semantics **package creation** >> >> when PI-Foo contains >> Foo >> Foo-Zork >> >> if we should create only one RFoo containing all the FooCat >> then we arrive to the point where this is not clear that >> when I add a new cat it will not be in. > > The solution I proposed was a new publishing interface for MC that works with > the 1-1 mapping between RPackage and PackageInfo. Like this, for saving we > would be force to save the new package. > > So, in your case, when you would open the NewMC, you would see in the list: > > Foo > Foo-Zork > Foo-Cat* > > The +Package button would disappear altogether. You would be provided with > the possible things to commit, and then you would not have to think about the > mapping at all. All you have to do is select each of the RPackages that you > want to commit, and if there does not exist a correspondent Monticello > package for it, you would be asked to provide the repo and then the creation > would happen transparently. > >> So we could always load and create a RPackage for each Category. This would >> be simpler. > > In your solution, you would again split the mapping logic of load from that > of publishing but you would change the loading mapping such that when you > load you create only one category per PI. Perhaps that is indeed simpler, but > you would lose the extra info of categories. > > > Were my explanations clearer now? > > > Cheers, > Doru > > > >> >>> Indeed, Metacello configurations will need modifications, but we have a >>> smooth path to it. The Metacello configurations are still typically used >>> only for loading and that will still continue to work just like they do >>> now. With the Metacello Browser things will change, but then again we can >>> change that tool, too. >>> >>> The only problem is how to define class extensions. I believe the * magic >>> mapping is in MC. That will create problems, but for a while, I think we >>> can still rely on this mapping. >> >> yes >> >>> >>> Cheers, >>> Doru >>> >>> >>> >>> On 19 Mar 2011, at 22:20, Stéphane Ducasse wrote: >>> >>>> >>>> On Mar 19, 2011, at 7:17 PM, Guillermo Polito wrote: >>>> >>>>> BTW, for smooth transition, why not just replace usages of PackageInfo by >>>>> RPackage keeping everything working as today? And after that, we can >>>>> improve the way we use it. >>>>> >>>>> In two words, why not replace only infrastructure instead of >>>>> infrastructure and behavior at the same time? Doing both together is >>>>> kind of complex and easy to make mistakes... >>>> >>>> yes this is what cyrille started to do. On top of RPackage so may be >>>> cleaning that is the way to go. >>>> but the matching semantics is not good. >>>> >>>>> But maybe it's easier (or nicer) to replace everything together... :P >>>>> >>>>> Guille >>>>> >>>>> On Sat, Mar 19, 2011 at 1:35 PM, Dale Henrichs <[email protected]> >>>>> wrote: >>>>> Stef, >>>>> >>>>> I would say that trying to diverge from category-based packaging for MC1 >>>>> would pretty much be a disaster. the big problem is not what happens >>>>> within Pharo (which is a tough enough problem to solve), but what happens >>>>> to other folks (Squeak or GemStone or even VW in this case) trying to use >>>>> mcz files created in Pharo that no longer align with the class and >>>>> method categories? It will not be pretty. >>>>> >>>>> On the other hand, MC2 has been designed from the beginning to allow for >>>>> alternate package definition schemes ... category-based packaging has >>>>> always been a hack.... >>>>> >>>>> Perhaps this is time to start a push towards MC2 and perhaps >>>>> RPackage-based packaging could become part of MC2 or at least one of the >>>>> packaging schemes ... >>>>> >>>>> For transition, MC1 would continue to use category-based packages and >>>>> those projects that wanted to preserve MC1 compatibility would simply >>>>> continue to name the categories to make MC1 happy and use RPackage for >>>>> MC2 packages with a different rule set ... >>>>> >>>>> One of the problems with MC2 has been the lack of a compelling reason to >>>>> make the transition to a new system ... RPackage and the associated tools >>>>> could be the compelling reason to move to MC2... >>>>> >>>>> Dale >>>>> >>>>> On Mar 18, 2011, at 1:56 PM, Stéphane Ducasse wrote: >>>>> >>>>>> Hi guys >>>>>> >>>>>> we need to think about package: >>>>>> >>>>>> right now we have a new implementation that is fast, robust and supports >>>>>> well a new generation of tools (glamour, nautilus...). >>>>>> We are capturing all system events and we would be more or less ready to >>>>>> remove systemNotifier and use Announcement >>>>>> instead. >>>>>> RPackage can live also on the side of PackageInfo for a while but it >>>>>> would be better to have the shortest possible period of co-existence. >>>>>> >>>>>> Now one of the problem I see is that we may not have a smooth transition >>>>>> because: >>>>>> - Rpackage does not rely on category tagging matching. >>>>>> - It is simpler to have a mapping from current categories to packages >>>>>> - Now it means that we could load a package in the system and it would >>>>>> be turned into several RPackages >>>>>> so this means that configuration would have to be adapted. >>>>>> >>>>>> - marcus was suggesting me to create a package with the same contents >>>>>> as the one of loaded by MC. >>>>>> and to have tags to only represent categories. >>>>>> >>>>>> Now my time is short so I will >>>>>> - probably not implement tags >>>>>> - check again the implementation of RPackage and in particular the >>>>>> necessary compatibility layer, because I saw some strange >>>>>> code. >>>>>> - check the MC dependency on method category conventions, because some >>>>>> logic is not defined in the right place >>>>>> like overrides in the MC tools and not in the PackageInfo >>>>>> - check how a package gets created when loaded: the key question is >>>>>> that there is a problem to rely on categories to >>>>>> associate classes to packages because we can end up with overlapping >>>>>> (normally the IDE captures the category renames >>>>>> and change the packages accordingly). >>>>>> - we should not rely on most-specific-category kind of pattern >>>>>> matching. >>>>>> >>>>>> So if you have suggestion please talk now. >>>>>> >>>>>> >>>>>> Stef >>>>> >>>>> >>>>> >>>> >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Every now and then stop and ask yourself if the war you're fighting is the > right one." > > > >
