Skip to content
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

Offline workflow #4

Closed
arcanis opened this issue Aug 27, 2020 · 6 comments
Closed

Offline workflow #4

arcanis opened this issue Aug 27, 2020 · 6 comments

Comments

@arcanis
Copy link
Contributor

arcanis commented Aug 27, 2020

Some users will not want to download things dynamically. This should be addressed in the available tools.

Proposed workflow:

A command (let's say pmm hydrate) would install a tarball within the package manager cache:

pmm hydrate yarn-1.22.4.tgz
# Yarn 1.22.4 is in the cache, no dynamic install
yarn --version

How these archives will be retrieved doesn't matter: users have the responsibility for that. Some popular options will be:

  • Store them directly within the repositories
  • Download them from a private registry
  • Cache them when building the docker images

To make the tarball creation easier, pmm would include a pmm pack yarn@1.22.4 command that would generate the tgz file for the given package manager (in a format suitable for pmm hydrate).

@arcanis
Copy link
Contributor Author

arcanis commented Aug 27, 2020

Of note, this would also enable private proxies & registries at no configuration cost: users would just have to fetch the tarballs themselves, using their preferred tools. Basic example:

wget https://user:password@binaries.my-company.com/yarn-1.22.4.tgz

@arcanis
Copy link
Contributor Author

arcanis commented Aug 27, 2020

cc @mmarchini

@mmarchini
Copy link

yeah, I think that works. Would it also be possible to have a global config file for pmm where we could set pmm to never download the package manager (useful for Docker images) or to always download without asking (useful for adventurous users on development environments), along other settings?

@arcanis
Copy link
Contributor Author

arcanis commented Aug 27, 2020

It could - one tricky thing with configuration variables is that .. well .. you need to load this configuration, and things get ever so slightly more complicated. Do you think keeping that as an environment variable would work? Something like:

PMM_FALLBACK_BEHAVIOR=<none|request|accept>

@mmarchini
Copy link

yeah, environment variables could work too. I think configuration files are more user-friendly (especially for users not super familiar with Unix systems or for Windows users), but env variables work especially if we have a really limited set of configuration options.

@arcanis
Copy link
Contributor Author

arcanis commented Sep 8, 2020

Implemented pmm pack & pmm hydrate + tests, along with the PMM_ENABLE_NETWORK environment value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants