<div dir="ltr"><div>[snip]</div>Sorry, when I said multiple Racket applications, I meant multiple applications written in racket.  E.g  If I had a web scraper/site monitor running constantly as well as a music manager.  They both use a html package, but need different versions of this package. Having multiple installations of Racket would certainly be an option, but what a horrible one.<div>
[/snip]</div><div><br></div><div>Actually, with </div><div><br></div><div>1. The movement towards a minimal Racket installation, and </div><div>2. Movement of many things into the package system</div><div><br></div><div>having a small Racket install for different projects won&#39;t be a big deal. And, you&#39;ve just suggested two projects that are, essentially, &quot;production&quot; services. I wouldn&#39;t run a production service on a constantly changing base. I would want my language and packages to remain constant, and I would only do upgrades of either when I knew there was a good reason (security updates, features) that required me to do so. If it&#39;s a cutting edge &quot;production&quot; service, then I&#39;m expecting to constantly upgrade everything, and the idea that I would freeze something seems counterintuitive.</div>
<div><br></div><div>So, all of this doesn&#39;t bother me at all. For a long time, I had tools that did not migrate from... er, possibly v4xx to v5xx?... because they &quot;just worked.&quot; They had a known lifetime, and it didn&#39;t matter to me that the Racket world had moved on. Some of them ultimately upgraded, some didn&#39;t. </div>
<div><br></div><div>Like Matthew said, the tools continuously improve. If it turns out the new package manager has obvious space for improvement in practice, the core team and community will, no doubt, address it.</div><div>
<br></div><div>Cheers,</div><div>Matt</div><div><br></div></div>