<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Ryan,<div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">Am 03.10.2020 um 03:00 schrieb Ryan Schmidt <<a href="mailto:ryandesign@macports.org" class="">ryandesign@macports.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">Just MacPorts did not implement it yet and when the necessity arose a seemingly simple workaround was chosen instead of solving the underlying problem.<br class=""></blockquote><br style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">As for MacPorts, it's not that we haven't implemented it because we're lazy.<span class="Apple-converted-space"> </span></span></div></div></blockquote></div><br class=""></div><div class="">my apologies for expressing this poorly enough to be misunderstood. I did not mean to suggest laziness was a reason to chose one way over another, neither in this case nor in general. <br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">It's because, besides being an unimaginably large amount of work in rearranging our code to do it, I have absolutely no idea how it would be accomplished without providing the user with unlimited opportunities to create broken combinations of port versions, which would generate an unlimited number of bug reports that we would then need to respond to, and my goal in MacPorts is to reduce, not increase, the likelihood that users would find something broken or need to contact us to help troubleshoot it.<br class=""><br class="">If you have an idea for how it could be done without such problems arising, please open a new topic and describe it and we can talk through a few scenarios and see if it works.<br class=""></blockquote><div class=""><br class=""></div><div class="">I do have some ideas (not mine, just looking at how it works elsewhere), but not the time to drive something of this size, to be honest. Basically, we'd need to </div><div class="">- keep and distribute all Portfile versions (including patches and files), not just the lastest</div><div class="">- add required versions to dependencies (can be version ranges e.g. >=1.2.3 or 2.* or 1.2.3-4.5.6)</div><div class="">- add support to install individual ports in into separate folders or give them individual names on install time (much like with the perl versions), so multiple versions of a port can be installed in parallel.</div><div class="">- add command line parameters to the port command so users can optionally specify a version to install (defaults to latest) and a pre/post fix to install location or file names or both (depends on how stuff gets implemented, of course)</div><div class="">- add support for dependency resolution including version information. So if two ports have different, non overlapping version requirements for a dependency, that dependency gets installed twice. Making sure each port then actually uses its matching version is probably one of the trickier parts here.</div><div class=""><br class=""></div><div class="">Implementing all this would be a major project and I totally understand that it's nothing to jump at without considering all the consequences and outside factors. </div><br class=""><blockquote type="cite" class="">I'm speaking of the user being able to specify an arbitrary version. </blockquote><div class=""><br class=""></div>So do I.</div><div class=""><br class=""><blockquote type="cite" class="">I consider it a feature, not a bug, that we offer multiple ports for different versions of perl, php, python, ruby, gcc, clang. It enables the user to install multiple versions of those languages that can all be active and available at the same time. If the user has one script that works with python 3.8 and another that requires python 3.6, no problem. If they have one web site that works with php 7.4 and another that needs php 7.2, no problem. If we only had a single python or php port that only let the user choose a single version to install at a time, that would not be possible.</blockquote><br class=""></div><div class="">I totally agree that this is a great feature. Only it's limited to a few versions of a few ports due to the way it's being implemented. Supporting this for more ports and version does not scale well, twice as many ports/versions cause twice as much work. With thousands of ports in the tree the current approach will always be limited to a handful of ports. If this was implemented as general features to a) install any port version and b) install several instances of any port, we'd get the same for each and every port/version out of the box.</div></body></html>