On Friday, May 1, 2020 at 9:01:41 AM UTC+8, Robby Findler wrote: > > 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)? > The "project" would be the toplevel folder where the source files for a Racket application (not a package) are located. Inside this folder, perhaps in a ".racket" sub-folder, the packages used by the application would be installed. Than, any `requires` inside this "project" folder will be resolved with packages from the .racket sub-folder first, than the other package scopes would be searched. Another Racket application would be another project and would have its package dependencies installed in its own .racket subfolder, these packages won't conflict with the packages from the first installation. If a "package-a" is installed in the first project, trying to use "(require package-a)" from a file in the second project will not find it. > 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? > To use an analogy with GIT, you can `cd` into one repository and run "git push origin" and it will push some commits to some remote location, than `cd` into a different directly and run the same "git push origin" and it will push a different set of commits to some other location. You don't tell your GIT installation that you switched projects, and you don't register your projects with your GIT installation in the first place, yet git was able to determine that "origin" in the first case means something else from "origin" in the second case. I am also interested in such a feature, and the examples I gave are only an overview on how I would like things work. It is also similar how NPM (the node package manager) does things. There are, of course many other things to consider and it might not be a trivial thing to implement. Alex. -- 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/edda4402-2203-4c91-b261-cd5f9a65f767%40googlegroups.com.
