Open MikeFultonDev opened 1 year ago
MikeFultonDev
commented
1 year ago Brew also has a list, and has a search that means to search metadata It has a 'cleanup' vs a 'clean' It has an 'update' (for brew itself) and an 'upgrade' It has a reinstall
So these 2 seem pretty consistent with one another.
MikeFultonDev
commented
1 year ago rpm uses 'query' instead of 'list' rpm has 'upgrade' and also a 'freshen' rpm has 'erase' instead of 'remove'
MikeFultonDev
commented
1 year ago apt has 'install', 'remove', 'upgrade'. It has 'search' and 'list --upgradeable' (I think I discovered where @DevonianTeuchter got his verbs from!)
v1gnesh
commented
1 year ago How about zopen self update for updating zopen (meta)?
Makes it pretty clear compared to just zopen update or zopen update zopen/meta.
Update/upgrade, whichever :smiley:
DevonianTeuchter
commented
1 year ago tldr; more separate scripts :-)
The initial list of verbs was based on various package managers and installers and included aliases to cover users coming from most of those backgrounds [and ones I'd used!] such as dpkg/rpm/apt/dnf/yum/yast/emerge/zypper/brew/chocolatey/pacman/... - initially there were even more aliases to try and map most of those but slimmed the options down already! :-) There's a good resource at https://wiki.archlinux.org/title/Pacman/Rosetta that compares a few package managers and their terminology/syntax
Aliases can work if the child script can determine how it was called so can display the appropriate help - however, for clarity, it might be that move more code into common.inc and separate items into their own modules that can be run standalone [ala #436 ] . zopen can still act as a thin wrapper to those modules much as it does today, passing the same arguments through the eval command as a caller of a zopen-* script would do.
With that being said, how about the following :
Keep [these scripts perform a standalone task]:
zopen-init - initial install script
zopen-generate - generate a basic template for a new port
zopen-alt - [could be zopen-alternatives but that's a lot of typing!?!] - used to switch versions
zopen-build - build packages from source
zopen-clean - clean resources
zopen-remove - remove package (rpm uses erase, others use remove but remove seems sensible)
Separate zopen-install into install, reinstall & upgrade [moving main function into common.inc] with options like localinstall and download-only having an effect as appropriate
zopen-install - handle installing new packages only
zopen-upgrade - handle upgrades/updates to existing packages (currently zopen install -u - update is used in some cases, with upgrade being more akin to a system-upgrade)
zopen-reinstall - reinstall existing packages (currently zopen install --reinstall which matches apt-get behaviour )
Seperate zopen-query into search, list & query [the funcitons are fairly separate as-is inside zopen-query]
zopen-search - search repo(s) for package information
zopen-list - list information about installed packages (zopen-query --list currently)
zopen-query - perform finer grained queries against local packages (like --whatprovides, --provides etc)
??
zopen-version - should this just cat what's in meta's .version file instead of hardcoding in two places? or just be a getVersion() in common.inc rather than an external program/script? and does it need --help since it's callable?
zopen-update-cacert - used to download certificates if needed.
Each individual script would then have it's own unique --help [discussion in #414 ] including zopen itself
Additional thoughts:
zopen-update self && zopen-update certs && zopen-update metadata or a --refresh on the zopen-upgrade to download fresh metadata/certs if needed?MikeFultonDev
commented
1 year ago I love it.
For your last point about common.inc, can we just create an 'inc' directory and have the tools include inc/common.inc ?
These get us a lot closer to what the other systems have.
I didn't know we have a .version file - I'll change that to do a cat... Yes - one place for everything...
Do we still need zopen-update-cacert? I'm fine to add it but what's the use case? Does this become more of a 'helper function' for cURL and git users? I don't think we need it internally anymore right?
IgorTodorovskiIBM
commented
1 year ago I love it. For your last point about common.inc, can we just create an 'inc' directory and have the tools include
inc/common.inc?
We should also change the suffix to .sh. I get annoyed that vim doesn't do the syntax highlighting accurately with .inc.
DevonianTeuchter
commented
1 year ago We should also change the suffix to .sh. I get annoyed that vim doesn't do the syntax highlighting accurately with .inc.
^THIS^ I've added an extra rule in VSCode so that it sees common.inc as a shell script rather than a pl/I include file [and so shellcheck runs on it].
v1gnesh
commented
1 year ago Hey why not include/ or includes/ like the usual /usr/include/<whatever> ?
DevonianTeuchter
commented
1 year ago Hey why not
include/orincludes/like the usual/usr/include/<whatever>?
other option might be
I'd like to streamline the verbs we support to be consistent with other package managers. I'd also like to eliminate aliases - I don't see much value in them and they are a good opportunity for getting doc out of sync.
DNF has been brought up a few times. It has the following verbs that match close to what we have:
There is a 'search' but it is not the same as ours - it instead searches meta-data for keywords. There is no 'query' command (which like search, is an alias for list for us)
I propose we eliminate
zopen install --upgradesince I see 'upgrade' as being different enough from 'install' to warrant it's own verb.I am ok with either keeping
zopen install --reinstallalthough consistency would seem a good reason to create a new verb 'reinstall'I notice they have
zopen list --upgradesinstead ofzopen list --upgradeable. I personally would be happy to switch, for consistency but probably more because I can never remember if upgradeable has one or two 'e's 😁@IgorTodorovskiIBM @DevonianTeuchter @HarithaIBM and anyone else... arrows expected...