Thanks for this, it really helps. I'm not sure what improvements can be made that A) wouldn't repeat the problems encountered in PLaneT and B) gives users an "easy" way to deal with breaking changes in collection names beyond what the Package Management FAQ suggests.
I remember Sam mentioning `raco link` in Slack, but based on your emails it sounds like NOTHING can fundamentally change without a tethered installation or custom distribution (e.g. a collects-like directory relative to a different executable). Is that correct? I wasn't sure if you were hinting at that in your first email. If that's the case, then I'd probably double down on my first reply: It almost seems like giving users an easy way to generate tethered installations would open up more opportunities than trying to make the default installation behave a certain way around packages, collections, and modules. ~slg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, May 21, 2020 10:50 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > FWIW: > > Changing the search path for modules isn't just about changing the > `current-module-name-resolver` parameter. Paths and search rules end up > getting used in subtly different ways by different tools, such as > `racket` versus `raco setup` versus `raco exe`. The module name > resolver is more of a hook than the definition of resolution. For > example, `raco exe` finds modules using its own search implementation, > but it sets the module name resolver in the generated executable; that > resolver to connects the modules found "statically" when building the > executable to the modules demanded dynamically at run time. > > One of the big shifts from Planet to the new package system was to > remove the process of package resolution from the module search path. > Module search is based on collections, and package management installs > collections. > > There are drawbacks to separating module search from package > resolution. I just wanted to note that we've tried both, and that > changing search rules can be a bigger and more invasive change than it > appears at first. > > At Thu, 21 May 2020 14:33:01 +0000, Sage Gerard wrote: > > > Thanks for the link. Is there a way to use the solver-based approach that's > > easier than involving a tethered installation or a custom launcher? On my > > end > > it looks like any different approach to packages would need a different > > module > > name resolver too. > > ~slg > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Thursday, May 21, 2020 10:16 AM, Sorawee Porncharoenwase > > sorawee.pw...@gmail.com wrote: > > > > > > There are basically two approaches in wide use here, depending on > > > > whether the underlying system was developed after this kind of package > > > > management approach became popular (npm, cargo, stack) or before > > > > (virtualenv for python and others). > > > > > > `stack` (Haskell) is a bit different from `npm` (JS): it installs a new > > > compiler for each project. I can't imagine how this approach could work > > > with > > > tools like DrRacket. > > > > > > > I know this touches on a reason why PLaneT had issues, but I don't > > > > understand how this is a problem. If two versions of the same package > > > > are in > > > > different locations on a filesystem and the module resolver can somehow > > > > distinguish the two using collection paths, then how else do they > > > > collide? > > > > > > IIUC, `npm` solves this problem by doing exactly this, but it is pretty > > > naive. A solver based approach can be more optimized: > > > http://www.well-typed.com/blog/2015/03/qualified-goals/. > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Racket Developers" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to racket-dev+unsubscr...@googlegroups.com. > > > To view this discussion on the web visit > > > [https://groups.google.com/d/msgid/racket-dev/CADcuegtP%2BKEDz4rPQV6uU%2B2yMofi > > > zwe12Tb0MX1B24zWGjHE-w%40mail.gmail.com](https://groups.google.com/d/msgid/rack > > > et-dev/CADcuegtP%2BKEDz4rPQV6uU%2B2yMofizwe12Tb0MX1B24zWGjHE-w%40mail.gmail.com > > > ?utm_medium=email&utm_source=footer). > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-dev+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/racket-dev/4S48b8dOz7vS_k2y1cbrBocbl0IHRsLV9u > > 24M-wSw31KL9bpBZ5Pi-9VowKZIoJSP6MlLJ9UFwUpqLXab5IoypbFf0lbmV-iQYYXUv_AArE%3D%40 > > sagegerard.com. > > -- > > You received this message because you are subscribed to the Google Groups > "Racket Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/20200521085037.1f0%40sirmail.smtp.cs.utah.edu. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/81I3zNgPOcinNAb6IAHexHz2ppgDYxc_Yz2wqtzbFY1VjGk2x9oLLAz_Wtyp-Rk_SNtfd26Pp27gRT4E_V51Wyr1qsWv2UkLGkot0_qqlf4%3D%40sagegerard.com.
