Intro Some folks working on Nim tooling were discussing Nimble and how it works with package caches. It also overlaps with how Nimble parses information from nimble files in each project which plays a role in properly using SAT for package resolution. Currently Nimble mixes Go-like vendoring style with that of a package manager style. This unfortunately ends up with the worst aspects of both as discussed in other RFC's (Nim RFC 524, Nimble RFC 653). Currently Nimble uses Git to clone a package from a repository url. This cloned repo is used to parse the project's Nimble file and find tagging informating for versions. The "source files" folder is then copied into Nimble's cache directory, the meta data is cached, and the cloned repo is removed. The repo remains the defacto source of information for the package metadata while the source files are transformed into a new structure. This process runs into many issues, including cloning a repo multiple times for different versions, inconsistencies in metadata, etc. This RFC builds on an idea that arnetheduck suggested. The idea is that Nimble should instead keep git clones in its global cache and "instantiate" their work trees in a local project folder. This would resolve many issues with networking, storage, and locality. Nimble could further embrace a traditional package manager design where a central metadata server would be used to store versioning information and possibly files themselves. However, this would require a large change in how the Nim and Nimble ecosystem works. It also requires dedicated resources to maintain such a system, especially from a security standpoint. Building on resources like Github, Gitlab, etc offloads those issue and allows users flexibility in their setup. Proposed Design