As you explain it, I understand RPackage is nothing more than a cache
maintained by virtue of SystemAnnoucements.
That's a huge effort for a small revolution.
I'm sure there are other goals behind, or were there postponed due to MC?
aMCPackage is a set of RPackages whose name beginsWith: aMCPackage name
A well known mess with MC is when aMCPackageA name beginsWith: aMCPackageB name,
then aMCPackageA is included into aMCPackageB
As long as, 1 RPackage = 1 category exactly, there is no such mess
with RPackage, a class belongs to a single RPackage.
Extension methods are less clear, and seem those in protocols that
beginsWith: ('*' , aRPackage name)
Possible mess this time
aRPackageA name beginsWith: aRPackageB name
the methods will belong to several RPackage?
Now if I create protocols '*MyOwnCruft-core' then a new category
('MyOwnCruft'), I believe the organizer or the new RPackage must scan
all existing protocols to catch extension methods... Does that happen?
Nicolas
2012/9/7 Esteban Lorenzano <[email protected]>:
> Hi,
>
> On Sep 7, 2012, at 10:08 PM, GOUBIER Thierry <[email protected]> wrote:
>
>> It's hard to converse with that Exchange webmail. Oh, Ok, here it goes.
>>
>> The one MCPackage _ One RPackage I'm Ok with, I made that working with my
>> browser. But if this is the goal, then the current code is almost there and
>> option 2) isn't needed ? A RPackage (the one with tags) clearly represent
>> well what a MCPackage can be, bugs apart. (technically, it's a bit wider,
>> since extension methods may belong to any protocol, not just the
>> *PackageName : the AltBrowser consequently hides the extension name, which
>> is interesting at the GUI level and works very well).
>
> That's not the goal... that *was* the goal. The goal is to have a good
> representation of the system with RPackage.
> And no, we were not close, we were very far away to be close.
> Here is the thing 1 MCPackage = 1 RPackage breaks everything. Tags are just
> tags and don't have coherence with Class Categories.
> Now, 1 MCPackage = N RPackage has much more sense because stresses a lot less
> the system.
>
> Now, what Stef is saying is that we wanted 1 to 1 correspondence, but a lot
> larger granularity... that means MCPackage matching current class categories.
> Not the opposite... but that means we need to ask everybody to adapt their
> monticello and configurations to match that vision, and that's something that
> it's not going to happen, not just because, for instance, Seaside has already
> tons of packages, do you imagine with the proposed granularity?
> Also, Versionner or other tools can help to reduce the fear to that
> granularity in the future, but that's not going to happen tomorrow.
>
> So, I'm really sorry your work was almost ported and we changed the rules...
> and I'm sorry that while looking for the best solution for everybody we some
> times break somethings, but that's are the risks of developing over bleeding
> edge :(
>
>>
>> The only thing needed is to make sure than when Monticello says X belongs to
>> MCPackage A, that RPackageOrganizer doesn't say that X belongs to RPackage B
>> instead, and the reverse. There is a fault in the RPackage introduction
>> there, which is that both RPackageOrganizer and Monticello are tracking
>> system announcements, and giving them different meanings (and RPackage
>> propagate its changes to Monticello). I am at around 10 Pharo images I had
>> to scrap because the damage done by those bugs was beyond repair.
>>
>> When you say force people to have one class category, one RPackage, that I
>> do not understand why. As stated above, you have everything to handle
>> multiple class categories in a RPackage. Why add a RPackageSet layer above ?
>> Why make the transition break that ?
>
> "Force" is a strong word. We don't force anyone... RPackage is a construction
> with a purpose, not a general malleable tool. It is not a tool to create your
> package with your desired format. Is a way to represent the fact that system
> is composed from classes, who are grouped in units called categories.
> Categories are there for the human eye, not for the system... now, the common
> convention around those categories is that you see them in class declaration,
> as class categories, and in browser "packages" panel. Monticello packages, in
> other term, are conceptually collections of class categories packaged
> together.
> So... for me is important to maintain that notion.
> Now, there are two point of views:
> 1) you have a new completely different infrastructure (aka RPackage+tags) to
> represent system, and then adapt (I can say "force" too) all the tools to
> this (which is a lot of work). For me it looks like a hack (we have something
> and we force the tools to show other thing, just because), and also no real
> necessity to do it, or
> 2) we took our new packaging system and make it work in the most simplest way
> possible, focusing on maintain the system as close to the eyes as possible.
> RPackageSet represents a notion for Monticello packages grouping packages
> (and btw, it can disappear in the future, because RPackageSet responsibility
> belongs most probably to regular MCPackages), and RPackage instances who
> matches to what users expect most probably about the organization categories
> in their system.
>
> Our error was trying to take approach 1 first... not take path approach 2
> now... and it was an error because after one month of working on that
> direction, the system was more and more unstable and chaotic and complex, and
> not what it should happens, which was the opposite.
>
>>
>> (RPackage is not, in my opinion, naming agnostic. The main bugs I found in
>> RPackage are because someone believe it is, where it isn't)
>
> you're right, it is not.
>
>>
>> One thing I would suggest is : remove Monticello from system announcements.
>> Make RPackageOrganizer in charge of updating the MCWorkingCopy as needed
>> (have a coherent view of the system).
>
> That just don't work. If we remove monticello from SA, monticello doesn't
> know what changed and needs to reconstruct every time its state... which also
> means that monticello gui cannot be updated either.
>
> Esteban
>
>>
>> Thierry
>>
>> ________________________________________
>> De : [email protected]
>> [[email protected]] de la part de Stéphane Ducasse
>> [[email protected]]
>> Date d'envoi : vendredi 7 septembre 2012 21:37
>> À : [email protected]
>> Objet : Re: [Pharo-project] RPackage, Monticello and the removal of
>> PackageInfo
>>
>> On Sep 7, 2012, at 8:44 PM, GOUBIER Thierry wrote:
>>
>>> 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 :-(.
>>
>>
>> you are not the only one. Benjamin too.
>> Now we are fighting with it and this is just not for fun.
>>
>>
>>> Is there a plan to have clear semantics of the different matches planned
>>> (extension categories and sub categories, class category, package
>>> sub-category) ?
>>
>> Yes
>> Ideally we want
>> one MCPackage - one RPackage + tags
>>
>> Nothing more (no class category, no package info).
>> Now we should be able to remove class categories.
>> But this does not work easily because everybody would have to rewrite
>> configurationOf for their projects (since each categories would be turned
>> into a package).
>> So may be when versionner will be working we can add a behavior to migrate
>> automatically configuration.
>>
>>
>> So esteban will see if his idea is working which leads to a first class
>> category and we can in a second period go more towards
>> one MCPackage - one RPackage with tagged classes.
>>
>>> 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) ?
>>
>> You forgot to add "crap in PackageOrganizer."
>> So yes it would be good to clean all that.
>> RPackage is totally agostic to naming conventions but we have to create them
>> and support backward compatibility.
>>
>>
>>
>
>
