-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local Global Cache of Packages #133
Comments
I think this feature would be very much welcome! Some design considerations:
|
I think that makes the most sense.
Sounds like you should open a separate issue for this.
Rather than brainstorm ideas, let's start broader in our thinking here. Context:
Principles
Outcome:
Possible UX: # Using a modified version of Fabrizo's command name,
# list all the package set versions we currently have cached
# in the local "global cache"
$ spago global-cache --list
# or maybe without the "--list" command
$ spago global-cache
# When installing packages for the first time, spago should
# default to installing the `upstream` part to the global cache,
# not the project local `.spago/` folder
$ spago install
# to disable this, one could use the below flag
$ spago install --no-global-caching
# When we want to clean the global cache, we can clean
# a specific version:
$ spago global-cache --clean
# what appears below is an idea for what would be printed to the console
You currently have these versions of package sets cached on your computer.
Indicate which you would like to delete by their corresponding number.
To delete multiple ones at the same time, separate their numbers by a space
# PureScript Compiler Package Set Date
-- ------------------- -----------------
1 0.12.1 2018-02-01
2 0.12.3 2019-01-01
3 0.12.3 2019-01-08
4 0.12.3 2019-02-04
5 0.12.3 2019-03-01
.....
10 0.13.4 2019-09-05
> 1 2 5
You have indicated that you want to delete the following package sets
# PureScript Compiler Package Set Date
-- ------------------- -----------------
1 0.12.1 2018-02-01
2 0.12.3 2019-01-01
5 0.12.3 2019-03-01
Is this correct (y=yes, all else = "no")
>y
Deleting the caches of the selected package sets. This make take a while...
Finished. Now, I don't know how much of the above idea is feasible or what complexities it would add to this program. |
@JordanMartinez great analysis! Some clarifications:
"Fixing how repos are downloaded" is definitely in the scope of this issue. It has to be changed anyways in order to implement this, so we might as well point out which are the problems of the current solution so the new one doesn't have them
Downloads happen "by package tag" and not "by package set tag".
There are some aspects that make all of this really hard:
Given the above, I propose that the global cache should work only for packages that:
This is so that we can query their tags via an API call, so we can reliably know if a reference is a branch or a tag. Implementation note: we should keep a small "GitHub index" in the global cache, that caches which tags are available for every package (so you don't have to look them up every time you install a project)
I would prefer flags to alter command behaviour instead of interactive mode, mainly because:
The reasons why I proposed
|
Oh.... that's what was meant. Yeah, that makes a heck of lot more sense.
That makes sense.
Also makes a lot of sense. There's just a lot of sense-making going on in your comments. |
Low priority.
Coming from this comment:
Similar to
bower
in that it has a caching mechanism, provide a cache of already-downloaded dependencies, so that they can be used across multiple projects on the same computer.Or something like that.
This would help lower the bandwidth my learning repo uses.
I'm not sure how hard this is to implement, nor whether it's a good idea (when full considerations are considered). At the very least, this can be further discussed. I started looking into Nix, but still haven't given it the attention it deserves.
The text was updated successfully, but these errors were encountered: