<div dir="auto">Hi all,<div dir="auto"><br></div><div dir="auto">Robert, nice work. Happy to see you making progress! Splitting the code makes sense to me. </div><div dir="auto"><br></div><div dir="auto">For anyone in the USA please do not  work on or contribute code to an unregistered repository. The only repository registered for use in the USA as far as I know is squeaksource. All other repositories should be registered with the U.S. government or stay away from it. Crypto code is still regulated in the USA. There is an exception for open-source crypto but that only applies if it is registered. I know I mention this a lot but I just want to make sure everyone knows and nobody gets in trouble.</div><div dir="auto"><br></div><div dir="auto">All the best,</div><div dir="auto"><br></div><div dir="auto">Ron Teitelbaum</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 7, 2020, 3:27 PM Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" rel="noreferrer">http://smalltalkhub.com/#!/~Cryptography/Cryptography/</a></div><div><a href="https://github.com/zweidenker/Cryptography" target="_blank" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">https://github.com/garduino/Cuis-Smalltalk-Cryptography</a></div><div>Maybe <a href="https://github.com/KenDickey/Cuis-Smalltalk-Crypto-NaCl" target="_blank" rel="noreferrer">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" rel="noreferrer">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" rel="noreferrer">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>
<br>
</blockquote></div>