yay/config.go

304 lines
7.2 KiB
Go
Raw Normal View History

package main
import (
"bufio"
"bytes"
"encoding/json"
"fmt"
"os"
"os/exec"
"strings"
alpm "github.com/jguer/go-alpm"
)
2017-05-07 03:43:49 +02:00
// Verbosity settings for search
const (
NumberMenu = iota
Detailed
Minimal
)
// Describes Sorting method for numberdisplay
const (
BottomUp = iota
TopDown
)
type targetMode int
const (
ModeAUR targetMode = iota
ModeRepo
ModeAny
)
2017-05-07 03:43:49 +02:00
// Configuration stores yay's config.
type Configuration struct {
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 15:44:38 +02:00
BuildDir string `json:"buildDir"`
Editor string `json:"editor"`
EditorFlags string `json:"editorflags"`
MakepkgBin string `json:"makepkgbin"`
2018-07-18 01:53:53 +02:00
MakepkgConf string `json:"makepkgconf"`
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 15:44:38 +02:00
PacmanBin string `json:"pacmanbin"`
PacmanConf string `json:"pacmanconf"`
TarBin string `json:"tarbin"`
ReDownload string `json:"redownload"`
ReBuild string `json:"rebuild"`
AnswerClean string `json:"answerclean"`
AnswerDiff string `json:"answerdiff"`
AnswerEdit string `json:"answeredit"`
AnswerUpgrade string `json:"answerupgrade"`
GitBin string `json:"gitbin"`
GpgBin string `json:"gpgbin"`
GpgFlags string `json:"gpgflags"`
MFlags string `json:"mflags"`
SortBy string `json:"sortby"`
GitFlags string `json:"gitflags"`
2018-07-21 15:20:00 +02:00
RemoveMake string `json:"removemake"`
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 15:44:38 +02:00
RequestSplitN int `json:"requestsplitn"`
SearchMode int `json:"-"`
SortMode int `json:"sortmode"`
SudoLoop bool `json:"sudoloop"`
TimeUpdate bool `json:"timeupdate"`
NoConfirm bool `json:"-"`
Devel bool `json:"devel"`
CleanAfter bool `json:"cleanAfter"`
GitClone bool `json:"gitclone"`
Provides bool `json:"provides"`
PGPFetch bool `json:"pgpfetch"`
UpgradeMenu bool `json:"upgrademenu"`
CleanMenu bool `json:"cleanmenu"`
DiffMenu bool `json:"diffmenu"`
EditMenu bool `json:"editmenu"`
CombinedUpgrade bool `json:"combinedupgrade"`
UseAsk bool `json:"useask"`
}
2018-06-19 12:31:39 +02:00
var version = "7.885"
// configFileName holds the name of the config file.
const configFileName string = "config.json"
// vcsFileName holds the name of the vcs file.
const vcsFileName string = "vcs.json"
2017-08-04 11:26:53 +02:00
// baseURL givers the AUR default address.
const baseURL string = "https://aur.archlinux.org"
// useColor enables/disables colored printing
var useColor bool
// configHome handles config directory home
var configHome string
// cacheHome handles cache home
var cacheHome string
// savedInfo holds the current vcs info
var savedInfo vcsInfo
// configfile holds yay config file path.
var configFile string
// vcsfile holds yay vcs info file path.
var vcsFile string
// shouldSaveConfig holds whether or not the config should be saved
var shouldSaveConfig bool
// YayConf holds the current config values for yay.
var config Configuration
// AlpmConf holds the current config values for pacman.
var alpmConf alpm.PacmanConfig
// AlpmHandle is the alpm handle used by yay.
var alpmHandle *alpm.Handle
// Mode is used to restrict yay to AUR or repo only modes
var mode targetMode = ModeAny
func readAlpmConfig(pacmanconf string) (conf alpm.PacmanConfig, err error) {
file, err := os.Open(pacmanconf)
if err != nil {
return
}
conf, err = alpm.ParseConfig(file)
if err != nil {
return
}
return
}
2017-05-07 03:43:49 +02:00
// SaveConfig writes yay config to file.
func (config *Configuration) saveConfig() error {
marshalledinfo, _ := json.MarshalIndent(config, "", "\t")
in, err := os.OpenFile(configFile, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0644)
2017-05-07 03:43:49 +02:00
if err != nil {
return err
}
defer in.Close()
_, err = in.Write(marshalledinfo)
if err != nil {
return err
}
err = in.Sync()
return err
}
func defaultSettings(config *Configuration) {
config.BuildDir = cacheHome
config.CleanAfter = false
config.Editor = ""
config.EditorFlags = ""
config.Devel = false
config.MakepkgBin = "makepkg"
2018-07-18 01:53:53 +02:00
config.MakepkgConf = ""
2017-05-07 03:43:49 +02:00
config.NoConfirm = false
config.PacmanBin = "pacman"
2018-05-31 17:36:36 +02:00
config.PGPFetch = true
config.PacmanConf = "/etc/pacman.conf"
config.GpgFlags = ""
config.MFlags = ""
config.GitFlags = ""
2017-05-07 03:43:49 +02:00
config.SortMode = BottomUp
config.SortBy = "votes"
config.SudoLoop = false
config.TarBin = "bsdtar"
config.GitBin = "git"
config.GpgBin = "gpg"
config.TimeUpdate = false
2017-07-07 01:25:49 +02:00
config.RequestSplitN = 150
config.ReDownload = "no"
config.ReBuild = "no"
config.AnswerClean = ""
config.AnswerDiff = ""
config.AnswerEdit = ""
config.AnswerUpgrade = ""
2018-07-21 15:20:00 +02:00
config.RemoveMake = "ask"
config.GitClone = true
config.Provides = true
config.UpgradeMenu = true
config.CleanMenu = true
config.DiffMenu = true
config.EditMenu = false
config.UseAsk = false
Separate Pacman upgrade and AUR Upgrade by default Currently When performing a system upgrade, Yay will first refresh the database then perform the repo and AUR upgrade. This allows Yay to add some features such as better batch interaction, showing potential dependency problems before the upgrade starts and combined menus showing AUR and repo upgrades together. There has been discussion that this approach is a bad idea. The main issue people have is that the separation of the database refresh and the upgrade could lead to a partial upgrade if Yay fails between the two stages. Personally I do not like this argument, there are valid reasons to Yay to fail between these points. For example there may be dependency or conflict issues during the AUR upgrade. Yay can detect these before any installing actually starts and exit, just like how pacman will when there are dependency problems. If Yay does fail between these points, for the previously mentioned reasons or even a crash then a simple refresh will not cause a partial upgrade by itself. It is then the user's responsibility to either resolve these issues or instead perform an upgrade using pacman directly. My opinions aside, The discussions on the Arch wiki has reached a decision, this method is not recommended. So to follow the decided best practises this behaviour has been disabled by default. This behaviour can be toggled using the --[no]combinedupgrade flag It should be noted that Yay's upgrade menu will not show repo packages unless --combinedupgrade is used.
2018-06-22 15:44:38 +02:00
config.CombinedUpgrade = false
}
// Editor returns the preferred system editor.
func editor() (string, []string) {
switch {
2017-08-04 11:26:53 +02:00
case config.Editor != "":
editor, err := exec.LookPath(config.Editor)
if err != nil {
fmt.Println(err)
} else {
return editor, strings.Fields(config.EditorFlags)
}
fallthrough
case os.Getenv("EDITOR") != "":
editorArgs := strings.Fields(os.Getenv("EDITOR"))
editor, err := exec.LookPath(editorArgs[0])
if err != nil {
fmt.Println(err)
} else {
return editor, editorArgs[1:]
}
fallthrough
case os.Getenv("VISUAL") != "":
editorArgs := strings.Fields(os.Getenv("VISUAL"))
editor, err := exec.LookPath(editorArgs[0])
if err != nil {
fmt.Println(err)
} else {
return editor, editorArgs[1:]
}
fallthrough
default:
fmt.Println()
fmt.Println(bold(red(arrow)), bold(cyan("$EDITOR")), bold("is not set"))
fmt.Println(bold(red(arrow)) + bold(" Please add ") + bold(cyan("$EDITOR")) + bold(" or ") + bold(cyan("$VISUAL")) + bold(" to your environment variables."))
for {
fmt.Print(green(bold(arrow + " Edit PKGBUILD with: ")))
editorInput, err := getInput("")
if err != nil {
fmt.Println(err)
continue
}
editorArgs := strings.Fields(editorInput)
editor, err := exec.LookPath(editorArgs[0])
if err != nil {
fmt.Println(err)
continue
}
return editor, editorArgs[1:]
}
}
}
// ContinueTask prompts if user wants to continue task.
//If NoConfirm is set the action will continue without user input.
func continueTask(s string, cont bool) bool {
2017-08-04 11:26:53 +02:00
if config.NoConfirm {
return cont
}
var response string
var postFix string
yes := "yes"
no := "no"
y := string([]rune(yes)[0])
n := string([]rune(no)[0])
if cont {
postFix = fmt.Sprintf(" [%s/%s] ", strings.ToUpper(y), n)
} else {
postFix = fmt.Sprintf(" [%s/%s] ", y, strings.ToUpper(n))
}
fmt.Print(bold(green(arrow)+" "+s), bold(postFix))
len, err := fmt.Scanln(&response)
if err != nil || len == 0 {
return cont
}
response = strings.ToLower(response)
return response == yes || response == y
}
func getInput(defaultValue string) (string, error) {
if defaultValue != "" || config.NoConfirm {
fmt.Println(defaultValue)
return defaultValue, nil
}
reader := bufio.NewReader(os.Stdin)
buf, overflow, err := reader.ReadLine()
if err != nil {
return "", err
}
if overflow {
return "", fmt.Errorf("Input too long")
}
return string(buf), nil
}
func (config Configuration) String() string {
var buf bytes.Buffer
enc := json.NewEncoder(&buf)
enc.SetIndent("", "\t")
if err := enc.Encode(config); err != nil {
fmt.Println(err)
}
return buf.String()
}