Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

There should be `lunar enforce` that always answer 'yes' for module X #24

Closed
Phr33d0m opened this Issue · 8 comments

4 participants

@Phr33d0m

Okay, as we have discussed in #lunar , the same way lunar exile <#> exists (that always answers 'no' for module #), there should be a lunar enforce <#> that always answer 'yes' for module #.

@cavalier38 cavalier38 referenced this issue from a commit in cavalier38/lunar
@cavalier38 cavalier38 Added lunar enforce
enforced modules are stored in LUNAR_ENFORCE in the local config file
fixes #24
fe6d054
@cavalier38

If I should make this a true pull request, please let me know. If you know how to attach this commit as pull request, that would be even better. Since there are more commits pending to this

@Ratler
Owner

cavalier38 commented

If I should make this a true pull request, please let me know. If you know how to attach this commit as pull request, > that would be even better. Since there are more commits pending to this

You can't do that easily. Either you need to use one of the github wrappers for git, or you will have to attach a pullrequest to an issue using curl to post a specially crafted JSON blob to github :)

@cavalier38

I tried to attach a pull-request with curl. but I get "resource": "PullRequest", "code": "unauthorized", "field": "issue". Should I just create a new pull-request instead?

@sofar
Owner

I don't like that we're creating more config options. We implemented "held" much nicer.

Can we rewrite this so that /var/state/lunar/packages allows the following entries in the state field:

:installed:
:exiled:
:installed+enforced:
:installed+held:
:installed+held+enforced:

That would make this a lot more consistent, extensible in the future and probably a bit cleaner.

@cavalier38

The reason I didn't put it in there was, that we only had :exiled: :installed: and :held: but with these combinations this can be fixed. Just to be complete also is :enforced: without installed.
This would have a big impact as there are locations which check for :installed: and not with module_installed.
I'll create new branch to start working on this idea.

@cavalier38

I looked into this a bit further. And the change is not really trivial. add_module {un,}(hold,exile,enforce}_module should be handled differently. maybe use some add_module_status remove_module_status routines. The checks for :install: and :held: are no problem to fix.
Also there is backwards compatibility. Now, if you a module is :held: it implies :installed: that means that something like remove_module_status should handle this exception. Or lin lunar should convert this. Note: To go back you first need to lunar unhold $(lvu held) lunar unenforce $(lvu enforced).
Before I continue on this path. Is this worth the effort?

@cavalier38 cavalier38 referenced this issue from a commit in cavalier38/lunar
@cavalier38 cavalier38 Added lunar enforce
This includes changing the state to state flags separated with + in the
MODULE_STATUS files
Issue #24
747132d
@cavalier38

This new branch implements enforced using state flags. According to the description in the last few posts.

@sofar
Owner

+like.

Want to send a pull request?

@Ratler Ratler closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.