Ok, It's good to know, because, for me, as I was / I am trying to track the changes in RPackage for the past two weeks, it seemed that RPackage was happily oscillating between 1 and 2, and, to add to the fun, backporting it's instability by creating spurious packages in Monticello on the way. Oh well, I almost managed to stabilize on 1), now I'll have to recode for 2). Should have stuck to PackageInfo :-(. Is there a plan to have clear semantics of the different matches planned (extension categories and sub categories, class category, package sub-category) ? Monticello has already set a few conventions (not case sensitive, for example) (and they are not respected by quite a few packages) and not a few of the RPackage bugs are linked to it not respecting it (i.e. some methods of package matching in RPackage are case sensitive, whereas they are not in MCWorkingCopy) ? Thierry ________________________________________ De : pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] de la part de Esteban Lorenzano [estebanlm@gmail.com] Date d'envoi : vendredi 7 septembre 2012 18:13 Ã : Pharo-project@lists.gforge.inria.fr Development Objet : [Pharo-project] RPackage, Monticello and the removal of PackageInfo Hi, As you know, we want to replace the old PackageInfo structure with RPackage. Last weeks Pharo 2.0 has been really unstable because of this effort, and it will be unstable yet a few days more, so I want to review the actions we are taking, so you know why this happnes and the result we want to obtain. So... first: Why replace PackageInfo and PackageOrganizer? The short answer is: because they suck :) The more or less long answer is: because their existence introduces a lot of penalties in the system, and forces to a lot of workarounds to manage what should be a simple system categories manager... take for instance the match MCPackage-PackageInfo-Class categories. Each MCPackage maps to a unique PackageInfo, but package info contains string pattern matched class categories. Tools uses this and well... performance is frankly disappointing in many case. Like this, there are lots of other reasons. So... RPackage will solve this by keeping a view of the system, not having to calculate it everytime. RPackage will keep also the list of classes, extension, etc. so tools can operate with them in a better/faster way. Question is: How to migrate in the less painful way? Attempt 1) Let each RPackage be one PackageInfo. We first thought this was the best path so, we spend some time moving in that direction. The advantage is that migration from Monticello and PackageInfo is trivial, but then the problems started to happen: PackageInfo (and current RPackage) contains N class categories so, there is an impedance mismatch between what we was seeing and what users/tools expect (they work with class categories, not with RPackage or PackageInfo). To solve that, we added class categories as RPackage tags (yep RPackage allows you to tag classes). But then we need to update in ver annoying ways the tools. And we also has now the fact that class categories are now a tag into an RPackage. Something really obscure and that was causing a lot of pain... So, we rolled back... Attempt 2) Let each Class Category be one RPackage. Ok, this is very simple (and that's the beauty on it)... each tools and conventions will match perfectly. Only problem here is that now, Monticello is not compatible anymore. So, we worked on the concept of RPackageSet, to replace PackageInfo use into Monticelo packages (we need them to load/save packages and stay compatible). RPackageSet is exactly what its name says: a set of RPackage instances (created on the fly, by pattern matching, so, is still some kind of a hack), that is polymorphic with PackageInfo in the monticello context. Thus, everything in the system can remain unchanged (or almost no change, the refactoring engine needs some adjusts). One extra bonus with this approach is that it let us think on more cool refactors in the future: we can for instance replace class categories (now a symbol) with an RPackage... and continue simplifying the system in several ways. ...and that's where we are now. We are working hard on stabilizing the system, but that will take still some days more... after that, we will be really close to the PackageInfo removal. PLEASE: PackageInfo users, take this into account: PackageInfo will pass away... and is one of the parts of the system that cannot be deprecated, they has to be completely removed, prepare your tools for the rise of RPackage :) Cheers, Esteban