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.
