<div dir="ltr"><div>Hi Robert,</div><div>there are several possible ways we can split the package and still load the whole thing.</div><div>One is Metacello as indicated by Jakob.</div><div>It shines if wanting to support multiple dialects (Gemstone, Pharo, Squeak), multiple versions of these dialects, and multiple release of our own packages, with slightly different recipes concerning the package assembly.</div><div>It also shines for gathering pacakges from several repositories or handling complex pre-requisites (like FFI, Registers etc...).</div><div><br></div><div>Be warned that Pharo users did already tend to fork everything which lies on a squeak* repo when they did use MC.</div><div>With the transition to git, I doubt you maintain anything for Pharo if not for yourself.</div><div><a href="http://smalltalkhub.com/#!/~Cryptography/Cryptography/" target="_blank">http://smalltalkhub.com/#!/~Cryptography/Cryptography/</a></div><div><a href="https://github.com/zweidenker/Cryptography" target="_blank">https://github.com/zweidenker/Cryptography</a></div><div>By the way, I mistakenly uploaded two copies of Blowfish from Mariano Martinez Peck from smalltalkhub to <a href="http://www.squeaksource.com/Cryptography" target="_blank">http://www.squeaksource.com/Cryptography</a> This was not necessary because they did not add anything to Blowfish-PaulDeBruicker.10.mcz.<br></div><div><br></div><div>Cuis never used MC, so naturally also tend to republish packages with their own format and own repository on github (mostly traditional .st chunk !).</div><div><a href="https://github.com/garduino/Cuis-Smalltalk-Cryptography" target="_blank">https://github.com/garduino/Cuis-Smalltalk-Cryptography</a></div><div>Maybe <a href="https://github.com/KenDickey/Cuis-Smalltalk-Crypto-NaCl" target="_blank">https://github.com/KenDickey/Cuis-Smalltalk-Crypto-NaCl</a> can be of interest too.<br></div><div><br></div><div>This is not a critic for Cuis and Pharo, but just to underline that cross-dialect is de facto not the criterion for selecting the packaging techno.<br></div><br><div><div>If all packages lie in the same repository and no pre-requisites is required, then there is also a much less powerful, but so much simpler option of using a MonticelloConfigurationMap.</div><div>It is a simple .mcm file listing the sequence of MC packages and version to load.</div><div>Packages are loaded in the order prescribed by the .mcm, and it's possible to load latest versions (highest version numbers).</div><div>There are tools in image for constructing and saving those .mcm</div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le sam. 7 mars 2020 à 15:52, Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> a écrit :<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 dir="auto"><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Robert via Squeak-dev <<a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a>> schrieb am Sa., 7. März 2020, 15:39:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If only Monticello allowed for <br>
dependencies,  <br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">In fact it does. But it is never used so I suppose some piece is missing. </div><div dir="auto"><br></div><div dir="auto">What about Metacello? Most people use it for package dependency management nowadays.</div></div>
<br>
</blockquote></div>