<div dir="ltr">Thanks, Juan!<div><br></div><div>It's working like a charm now.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 26, 2020 at 11:14 AM Juan Vuletich <<a href="mailto:juan@jvuletich.org">juan@jvuletich.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div bgcolor="#ffffff">
    Yes, same fix there. I just pushed it to GitHub. I hope that's all,
    but if you find further trouble, please tell, and let's fix them.<br>
    <br>
    Thanks,<br>
    On 10/26/2020 1:44 AM, Nicolás Papagna Maldonado via Cuis-dev wrote:
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hi Juan,</div>
        <div><br>
        </div>
        <div>No worries! <font face="monospace">FakePackageClass</font>
          is a hack until I have time to write some tests and be able to
          break the dependencies and inject <font face="monospace">Smalltalk</font>
          and <font face="monospace">SystemOrganization</font> into <font face="monospace">CodePackage</font> instances, so these can
          be controlled from tests at will.</div>
        <div><br>
        </div>
        <div>I gave your fix a try but my package is still installed as
          an instance of <font face="monospace">FakeCodePackage</font>.</div>
        <div><br>
        </div>
        <div>After some debugging, it looks like <font face="monospace">CodePackageFile>>install</font>
          is checking whether any of the classes to be installed is a
          direct (just checks one level above) subclass of <font face="monospace">CodePackage</font>, and uses it to
          create the code package.</div>
        <div>Here's an extract of that method that (I believe) exposes
          that behavior:</div>
        <div><br>
        </div>
        <div><font face="monospace"><b>pckClass _ CodePackage</b>.<br>
              classes do: [ :ee |<br>
                (ee hasDefinition and: [<b>ee superclassName =
              'CodePackage'</b>]) ifTrue: [<br>
                  ee fileInDefinitionAndMetaclass.<br>
                  <b>pckClass _ Smalltalk at: ee name</b> ]].</font><br>
        </div>
        <div><br>
        </div>
        <div>From what I understand, the method I mentioned in my
          previous email is used in the <font face="monospace">postPackageInstall</font>
          phase, but this one happens before that.</div>
        <div><br>
        </div>
        <div>Should it be fixed too?</div>
        <div><br>
        </div>
        <div>Thanks for the help.</div>
        <div><br>
        </div>
        <div>Cheers!</div>
        <div>Nico PM</div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Sun, Oct 25, 2020 at 9:24
            PM Juan Vuletich <<a href="mailto:juan@jvuletich.org" target="_blank">juan@jvuletich.org</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div bgcolor="#ffffff"> On 10/25/2020 12:04 PM, Nicolás
              Papagna Maldonado via Cuis-dev wrote:
              <blockquote type="cite">
                <div dir="ltr">Hi Folks,
                  <div><br>
                  </div>
                  <div>For some experiments I'm doing, I've created a
                    subclass of <font face="monospace">CodePackage</font>
                    (let's call it <font face="monospace">FakeCodePackage</font>)
                    to make my tests run fast that avoids accessing <font face="monospace">Smalltalk</font> or <font face="monospace">SystemOrganization</font>.</div>
                  <div>When I filed-out the package and installed it in
                    a fresh image, to my surprise, the newly installed
                    package was an instance of <font face="monospace">FakeCodePackage</font>.</div>
                  <div><br>
                  </div>
                  <div>After poking around, I found this method in <font face="monospace">CodePackage</font> that is used
                    when saving an instance:</div>
                  <br>
                  <font face="monospace">codePackageClass<br>
                      "Answer the specific CodePackage subclass to use."<br>
                    <br>
                      self class == CodePackage ifFalse: [<br>
                        ^ self class ].<br>
                      self classesDo: [ :cls |<br>
                        (cls inheritsFrom: CodePackage)<br>
                          fTrue: [ ^ cls ]].<br>
                      ^ nil</font>
                  <div><br>
                  </div>
                  <div>This means that whenever there is a subclass of <font face="monospace">CodePackage</font> in the package
                    being saved, It is assumed that is the class that
                    should be used to re-creating the <font face="monospace">CodePackage</font> instance when
                    installing it.<br>
                  </div>
                  <div><br>
                  </div>
                  <div>In my case, <font face="monospace">FakeCodePackage </font>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.<br>
                    Luckily this was a fresh image, so I had nothing to
                    lose :)</div>
                  <div><br>
                  </div>
                  <div>I was wondering what is the use case for that,
                    and if it still relevant/in use.</div>
                  <div><br>
                  </div>
                  <div>Cheers!</div>
                  <div>Nico PM</div>
                </div>
              </blockquote>
              <br>
              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.<br>
              <br>
              Thanks,<br>
              <pre cols="72">-- 
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
            </div>
          </blockquote>
        </div>
        <br clear="all">
        <div><br>
        </div>
        -- <br>
        <div dir="ltr"><br>
          Nicolás Papagna</div>
      </div>
    </blockquote>
    <br>
    <br>
    <pre cols="72">-- 
Juan Vuletich
<a href="http://www.cuis-smalltalk.org" target="_blank">www.cuis-smalltalk.org</a>
<a href="https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev" target="_blank">https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev</a>
<a href="https://github.com/jvuletich" target="_blank">https://github.com/jvuletich</a>
<a href="https://www.linkedin.com/in/juan-vuletich-75611b3" target="_blank">https://www.linkedin.com/in/juan-vuletich-75611b3</a>
@JuanVuletich</pre>
  </div>

</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Nicolás Papagna</div>