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

gmailctl.libsonnet update #77

Closed
legeana opened this issue Jan 20, 2020 · 3 comments · Fixed by #265
Closed

gmailctl.libsonnet update #77

legeana opened this issue Jan 20, 2020 · 3 comments · Fixed by #265
Labels
good first issue Good for newcomers kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale.

Comments

@legeana
Copy link

legeana commented Jan 20, 2020

When the user runs gmailctl init the gmailctl.libsonnet is created. Unfortunately the file it never updated automatically again.
I propose gmailctl init --reset-lib or similar flag to force update all library files (current and future).
It is understandable that gmailctl will not rewrite config.jsonnet as it may contain user configuration, however library files are not expected to be touched by the user.

@mbrt
Copy link
Owner

mbrt commented Jan 20, 2020

Sounds reasonable!

@mbrt mbrt added kind/feature New feature or request good first issue Good for newcomers labels Jan 20, 2020
@mbrt mbrt added the lifecycle/keep-alive Denotes an issues or PR that should never be considered stale. label Apr 5, 2020
@paravoid
Copy link
Contributor

Why is the library copied in the first place though? If the user wants to override these functions, they can always copy it themselves and import it separately in their own configuration. Basically, I view gmailctl.libsonnet as gmailctl's stdlib, which can be expanded, updated, bugs fixed etc. and it'd all transparent to the user's config. Is that unreasonable?

@mbrt
Copy link
Owner

mbrt commented Sep 29, 2020

If the user wants to override these functions, they can always copy it themselves and import it separately in their own configuration.

Correct, however when this was implemented, I kept two things in mind:

  • The user will see the library on the side of their config, so if they have any doubt they can take a look at it easily, without having to look at the source code here.
  • Binary updates don't affect older installations, so as long as you keep the standard library you are using along with the config, you won't be affected even if new versions are released. This frees me from guaranteeing 100% compatibility for new library releases.

I think the way @legeana put it down is the safest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers kind/feature New feature or request lifecycle/keep-alive Denotes an issues or PR that should never be considered stale.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants