simoniz0r / spm

spm is a simple commandline package manager written in bash

spm

spm is a command line package manager that mainly provides AppImages. spm uses spm-feed.json from the releases page to get information about packages.

spm is not responsible for bugs within packages that have been installed using spm. Please report any bugs that are specific to installed packages to their maintainers.

Dependencies: curl, jq (jq is included in the AppImage release)

Arguments

    list|l      - list all available packages
    
    info|i      - output information for a package
    
    search|se   - search for available packages
    
    install|in - install a package to $TARGET_DIR
    
    get         - install a package to $GET_DIR without managing it
    
    remove|rm   - remove an installed package
    
    update|up   - update list of packages and check installed packages for updates
    
    revert|rev  - revert an updated package to its previous version if available
    
    freeze|fr   - mark or unmark a package as FROZEN to prevent update checks
    
    config|cf   - open spm's config file with $EDITOR

Additional Arguments

    [list|info] --installed|-i   - show list or info for installed packages

    --verbose [option] [package] - add bash option 'set -v' for verbose output

    --debug [option] [package]   - add bash option 'set -x' for debugging

Github Rate Limit

By default, Github's rate limit for API checks is 60 per hour. When authenticated, the rate limit is increased to 5000 per hour. To take advantage of the increased rate limit, it is suggested that you add your token to spm.conf.

It is recommended that you do not give this token access to any scopes as it will be stored in plain text in your config file. It may even be a good idea to create a throwaway account for use with this.

To use authenticated Github API checks with spm, edit the following line in ~/.local/share/spm/spm.conf to contain your token:

GITHUB_TOKEN="YOURTOKEN"

spm's Issues

Integrate with AppImageHub

Please check out https://github.com/AppImage/AppImageHub, i's a central database in-the-making for AppImages.

Let's discuss which output format would be optimal for you.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[suggestion] add streamlink-twitch-gui

Hello,
it would be nice if you could add this application to the repository of spm. It's an electron app for easier use of streamlink for Twitch.tv streams.

Repository: https://github.com/streamlink/streamlink-twitch-gui
Releases (only available as a .tar.gz as far as I know): https://github.com/streamlink/streamlink-twitch-gui/releases

(I'm also in the "Discord Linux" Discordserver if you should have any questions)

Add Hexinator to SPM's list of AppImages

https://hexinator.com/downloads/linux/Hexinator-x86_64.AppImage

Update concept

Not sure I entirely understand your update concept here, but with AppImages the authoritative information about where an AppImage should get updates from is inside the AppImage itself as per the AppImageSpec:

https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information

Trying to load information about the availability of potentially available updates from any other location than the update information embedded inside the AppImage itself is futile. Please do not do it, as it would be against the AppImage philosophy which mandates that update information has to travel inside the (signed) AppImage itself, not via a side-channel (which can easily be, and will in practice always be, outdated). Also, it would not work with AppImageUpdate binary delta (differential) updates.

spm/appimgfunctions.sh

Line 213 in e432ce6

appimgupdatelistfunc () { # Regenerate AppImages-direct.lst from github, download AppImages-github.lst from github, and check versions

Wording

Please avoid the word "install" in conjunction with AppImages. The point of the AppImage format is that an AppImage does not have to be installed in the traditional sense, only downloaded (and made executable, although appimaged can handle that and, in the future, signature verification automatically).

So if possible please replace the word "install" with "download".

[0.2.0.3] vscode missing

I have noticed that I can no longer search for or install vscode or any tar packages in the latest version of the appimage. This is a shame since it's the primary way I install vscode on various distros that don't have an easy method to grab it. Maybe supporting tar packages was a nightmare and removal was intentional or maybe this is a bug. In either case I hope this feature will return.

Keep up the great work! I recommend spm to all of my friends.

Plans

This issue is a list of things that I plan on implementing/changing in spm:

• Remove ssft.sh and create functions to replace it. Replace some text outputs in update argument with progress bars. Replace all completed messages with newly created message functions. Display info on install, uninstall, etc within these messages instead of as a separate message.

• Use one large json file to list all packages and use csplit to split it into separate json files that are easy to manage. This should reduce update check time when changes have been made to spm's repo by quite a bit.

• Add option at end of update argument to automatically start upgrades if they are available.

• Create revert function that stores last version of package before upgrading to new one with options for how many packages should be stored, etc. This also requires a freeze function to prevent future updates until the user OKs them.

Create functions that source in special instructions for AppImages and tars containing things such as update info for packages that can't be checked for updates, pre/post install instructions, etc.

• Add support for building AppImages not provided upstream using deb2appimage

Best way to implement appimage support in linuxbrew

hoping to get some advice/ideas from similar projects on this issue

(please excuse the copypasta 😅 thought this'd be the best combo of efficiency, related-github-repo-synnergy and visibility/discoverability for the relevant communities/contributers/etc)

I can run wget http://link , but at spm -ti gives me "failed"

[igor@localhost spm]$ ./spm -ti discord-canary 
Github API rate limit: 60/60 until 22:54:06, 2017-08-30.

cat: /home/igor/.config/spm/cache/discord-canary.conf: No such file or directory

discord-canary will be installed to /opt/discord-canary
Continue? Y/N y
Usage: wget [OPTION]... [URL]...

Try `wget --help' for more options.
wget https://discordapp.com/api/download/canary?platform=linux&format=tar.gz failed; exiting...

Downloads with direct links that need to be kept updated manually

These AppImages have links which do not redirect to the latest version automatically. I'm working on writing a script that I can run daily to check for new URLs so that updating these links doesn't have to be entirely manual on my end.

* = possibly remove from list

simplescreenrecorder*
repetier-host*
optifmus*
nextcloud
livezilla*
krita
kate
flexvdi*
audacity*
drawpile*
plex
blender*
falkon
ipe*
peruse
musescore*
nbb*
cutereport*
bscc*
rpcs3
serialplot*
voltra*
skycoin*
stopgo*
nootka
emu-player*
digikam
synfig*
cura
kdenlive
evothings*
openxcom
firefox

Make use of GitHub releases

Uploading archives of any kind, but especially releases, is horribly inefficient. Since this project is on GitHub, I'd suggest you to make use of it as a platform for release management as well.

First of all, by requiring you to tag a specific Git commit, a pure user of Git can understand what commit was responsible for which release, which is a plus when trying to e.g. find a bug in a specific commit. Furthermore, by tagging releases, they're shown in a nice way to GitHub users. Also, GitHub users will be able to automatically download a freshly generated tarball of the latest sources.

If you really feel the need to (e.g. when your release tarball needs to have a structure different from your repository, or you want to include binaries), you can also upload any kind of file to a "release".

So, to avoid any inefficiency in the repository, and further improve your release workflow, please consider using GitHub releases.

find a unique name for spm

https://github.com/topics/spm

shows that there are several "spm" . This makes finding stuff very hard.

maybe call spm "bashAppIm" for bash AppImage manager. or "bashman" like "pacman" in Arch-Linux.

https://github.com/topics/bashman

name collisions are a real pain. had trouble finding the real spm myself on github.