I'm trying to understand what you guys are talking about here and am not sure I'm getting it. Is the idea that a "project" (new term definition) would be a place one can install a package and its dependencies in a way that avoids any conflicts with other pkgs that are already installed (even if they are different versions of those same packages)? So I would have some command to configure my installation so that I would tell it what project I want to work with and then uses of `racket` after that would find requires inside the pkgs that belong to that project?
(Sorry if this is a dumb question; I'm very curious about this.) Robby On Thu, Apr 30, 2020 at 4:33 PM Matthew Flatt <[email protected]> wrote: > That's right: there's no one-step operation right now, and a new > one-step tool that sets things up the way you need would be a great > contribution. > > To avoid anything currently in user scope, maybe your new tool would > configure the project space with a fresh 'installation-name. After > setting 'pkgs-dir to be the project-specific package directory while > setting 'pkg-search-dir to chain to the original installation's package > directory, it could install some initial packages in the new > "installation" scope --- without affecting "user" scope or the original > "installation" scope. By setting 'lib-dir and 'shared-dir and similar > directories to a project-specific location, any files installed by > packages in the new "installation" scope would not pollute the old > installation. And so on. > > I'm not sure of the details, and it's possible that something new is > would still be needed in the collection or package or `setup/dirs` > layers to make the one-step tool work right. It's still possible that > the existing support doesn't do what you want at all. > > I'm unclear on whether you want to install packages in project scope > that would collide with things in the original "installation" scope, > but that's tricky at best. Conceptually, it works to install a package > in a narrower scope and shadow one in a wider scope, but only if > everything in the wider scope that depends on the shadowed package is > also shadowed in the narrower scope. If you want to be able to do that, > then probably this isn't the right direction. > > At Thu, 30 Apr 2020 20:54:33 +0000, Sage Gerard wrote: > > Some of the pieces are falling into place, but I'm still chewing on > something. > > > > Let me rephrase my goal with added details: As a library author, I need > my > > users to have ONE command that safely installs a package with collection > paths > > that would collide in a user or (system) installation scope. > > > > The docs on package scopes and your email make it sound like I have to > ask my > > users to create and configure an installation, and make sure no > colliding > > packages exist at user scope. All before installing the package. Can > your > > recipe be done in one step? If not, I think that's where I'd like to > > contribute. > > > > ~slg > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Thursday, April 30, 2020 3:24 PM, Matthew Flatt <[email protected]> > wrote: > > > > > Consider viewing "project" scope as "installation" scope, where an > > > existing installation becomes a wider scope after "installation". Then, > > > the exiting configuration and scope machinery will match what you need. > > > > > > If you take that view, then a project gets its own "etc" where you put > > > a "config.rktd" to configure the project-as-installation. That > > > "config.rktd" can point to the original installation as the next layer > > > for various searches: "collects", "lib", and so on. > > > > > > You can even set `config-tethered-console-bin-dir` and > > > `config-tethered-gui-bin-dir` to get project-local `racket`, `raco`, > > > etc., executables that have the right configuration path built in, > > > instead of having to use something like environment variables to select > > > a project's configuration. > > > > > > At least, that's one of the intentions of the existing layers. I didn't > > > push it further (e.g., to a `raco` command that would set up a project > > > in this sense) because there was not demand at the time. > > > > > > At Thu, 30 Apr 2020 19:10:11 +0000, Sage Gerard wrote: > > > > > > > Alright, so after thinking about how to improve Racket package > management I > > > > decided that I want to add project scoping logic to raco pkg > install. I'm > > not > > > > sure --scope-dir is enough because the docs say that the > installation is > > > > apparently checked before the scoped directories, and there are no > lock > > files. > > > > Correct me if I'm wrong. > > > > I've previously made commitments re: a CI dashboard and a syntax > > highlighter. > > > > Those remain, but don't seem to need me right this minute. > Meanwhile, this > > is > > > > one of those features that hurts to not have, especially with current > > > > limitations in the default package catalog. > > > > https://akkuscm.org says it supports plt-r6rs, so I > > > > see two paths: Either implement the diff between that and Racket > today in > > > > Akku, or add just enough of Akku to a raco pkg install --scope > project > > > > command. I expect both efforts would be painful, but the latter > seems > > better. > > > > Are there any landmines are in the raco pkg install code that I need > to > > know > > > > about? I'd rather not make a bunch of changes with subtle > consequences that > > > > I'm not seeing. I'd also like to know who would be the best person > to > > review > > > > my proposed changes in this area. > > > > ~slg > > > > -- > > > > 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 [email protected]. > > > > To view this discussion on the web visit > > > > > > > https://groups.google.com/d/msgid/racket-dev/04pE-yKBt1FzXg9NpgHlRoMEPSp3rIKJMJ > > > > > > > fzPRd7HBHxyF1gEwxK70y4uFONwvTXUADMdH5_Yz-Xy7fHA7XrbWe6NYYHXvE65gvPZ4H_uNU%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 [email protected]. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/racket-dev/5eab25df.1c69fb81.8f98.25f6SMTPIN_ > > ADDED_MISSING%40gmr-mx.google.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 [email protected]. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/racket-dev/il5M1m5pESWE_CWHdsPHg9WvQ5BhXin9sT > > > UJ9KMwaoKzuZldA1874eMaM5py5OFrsd23Az6Kr9mH69YblDfqrGS77flNW3BnwVzQGvygG84%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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-dev/5eab440d.1c69fb81.87557.2d50SMTPIN_ADDED_MISSING%40gmr-mx.google.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdOOgXhcPV-ppNy%3D%2Be%2B_LU6B-1jd-L1jmUiZT%2B6O9WYCa4g%40mail.gmail.com.
