[Cuis-dev] Saving a CodePackage and determining its class when installing it

Juan Vuletich juan at jvuletich.org
Sun Oct 25 17:24:46 PDT 2020

On 10/25/2020 12:04 PM, Nicolás Papagna Maldonado via Cuis-dev wrote:
> Hi Folks,
> For some experiments I'm doing, I've created a subclass of CodePackage 
> (let's call it FakeCodePackage) to make my tests run fast that avoids 
> accessing Smalltalk or SystemOrganization.
> When I filed-out the package and installed it in a fresh image, to my 
> surprise, the newly installed package was an instance of FakeCodePackage.
> After poking around, I found this method in CodePackage that is used 
> when saving an instance:
> codePackageClass
>   "Answer the specific CodePackage subclass to use."
>   self class == CodePackage ifFalse: [
>     ^ self class ].
>   self classesDo: [ :cls |
>     (cls inheritsFrom: CodePackage)
>       fTrue: [ ^ cls ]].
>   ^ nil
> This means that whenever there is a subclass of CodePackage in the 
> package being saved, It is assumed that is the class that should be 
> used to re-creating the CodePackage instance when installing it.
> In my case, FakeCodePackage is not fully functional as I use it only 
> in my tests, so I was unable to either delete the package or 
> re-install it because of all sorts of errors.
> Luckily this was a fresh image, so I had nothing to lose :)
> I was wondering what is the use case for that, and if it still 
> relevant/in use.
> Cheers!
> Nico PM

Too bad you found this bug. I hadn't thought of people writing 
subclasses of CodePackage, unless for instantiation of the package 
itself. This is used by ColorExtrasPackage and MorphicMisc1Package. It 
is only used to run #prePackageInstall and #postPackageInstall, and I 
don't think it is a clean solution. Anyway, I just posted a fix to that 
method, to also check for the package name.


Juan Vuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201025/70648067/attachment-0001.htm>

More information about the Cuis-dev mailing list