search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.66k stars 554 forks source link

Mass downloading of a list of AppImages #631

Closed probonopd closed 6 years ago

probonopd commented 6 years ago

@pbeccard on https://twitter.com/pbeccard/status/954778344897249281:

mass (re)install utility. I want to throw a list of URLs/Names/IDs to appimaged/AppImageUpdate (or some other program) and then have that program download the apps into the correct dir

Why not copy over the whole directory of AppImages (a big advantage of AppImages over installed applications imho)?

First of all, the download does not take that long. Also I don't want to throw them into my backup (I prefer a small backup and a backup that only contains non recoverable (not redownloadable) data). If I have to recover my system from my backup I want to restore everything.

TheAssassin commented 6 years ago

So, what's the point of this issue? Create a utility for downloading files by URLs? That's what wget, curl, and aria2 are for. Or do they ask for a tool interfacing with AppImageHub trying to find the release URLs, and then downloading the files (I think that should be fairly easy, you could just pipe the output of such a tool into your favorite download app, e.g., aria2 and wget take a list of URLs from stdin)?

Maybe you should tell the person on Twitter to come here and describe their idea.

The backup point, well, good backup tools have deduplication, so you'd have those AppImages only once in your backup tree. But that's just a tip aside, I think the person just went to excluding that directory. Another idea I have is to create a separate partition with an extra file system and put all the AppImages on that, maybe even mount that read-only.

corppneq commented 6 years ago

Life is to short for a manual installation.

@TheAssassin That's the point. I don't want the AppImage in the backup. Currently during my system installation I have a long list of packages that I install. It's just one apt-get install * command and everything is there. I don't want to redownload every AppImage manually.

What I would like to do is:

  1. Tell some AppImageUtil to read the list of my AppImages and store the update urls in a file
  2. Read that file (e.g. on a new system) and download all the AppImages

The download could be done with wget but I still need to extract the urls

probonopd commented 6 years ago

What is the reason that you don't want to make an update of your AppImages, but are willing to redownload them? They might even no longer be provided for download, at least in the same version...

Life is to short for a manual installation.

With AppImages, no installation is needed. Just copy the whole directory of AppImages from the source machine to the target machine, done.

corppneq commented 6 years ago

I'm not talking about a running system. If I reinstall a system (or install a new one) I want to have a completly automatic installation. With apt-get that just works. I just throw the package list to apt and apt downloads them.

With AppImage the only way to automatically download all the AppImages that I want would be the update urls. That why I need a tool that can export the update url (and preferably the key ID).

Edit: I always want the latest version.

TheAssassin commented 6 years ago

That sounds like a perfect "community project", to be honest.

It's fairly easy to use appimageupdatetool (or, even better, libappimageupdate) to read the update information from the AppImages, and then store that in some file. Is there anyone who wants to code that for @corppneq?

corppneq commented 6 years ago

I guess I could do that myself. I am currently just a bit busy preparing for some exams. I would say lets keep the feature request open and just wait a bit.

TheAssassin commented 6 years ago

Agreed. Maybe I have a few minutes today and can come up with something.

shoogle commented 6 years ago

What Linux is missing (ironically) is a package installer like scoop for Windows, or homebrew for macOS, which use scripts to download self-contained binaries directly from the upstream developers and then automate the installation process (which is per-user by default).

(Of course, Linux has plenty of package managers, like yum and apt-get, but those require special packages and repositories that must be created and maintained separately to the upstream code, whereas scoop and homebrew simply automate the installation of upstream binaries.)

Take scoop for example, it simply consists of a collection of installation scripts for various apps, and the scoop binary itself which runs the scripts. The scripts are stored in JSON format in a central git repository, which makes it extremely easy for anyone to edit them and keep them up to date.

If you run scoop install python, all this does is:

  1. Check the central git repository for the latest python.json and download it.
  2. Download python from the upstream location defined in python.json.
  3. Install python with the options defined in python.json, and put it in the user's %PATH%.

You can imagine doing something like this with appimaged, or similar.

P.S. YAML is easier to read and write than JSON!

azubieta commented 6 years ago

I think that a software center with a CLI is what you need. It happens that there is one that actually knows about all the appimage in appimagehub, what is missing is the cli. So please take a look at the nx-software-center code. Pr are wellcome

El 27 ene. 2018 4:18 PM, "Peter Jonas" notifications@github.com escribió:

What Linux is missing (ironically) is a package installer like scoop http://scoop.sh/ for Windows, or homebrew https://brew.sh/ for macOS, which use scripts to download self-contained binaries directly from the upstream developers and then automate the installation process (which is per-user by default).

(Of course, Linux has plenty of package managers, like yum and apt-get, but those require special packages and repositories that must be created and maintained separately to the upstream code, whereas scoop and homebrew simply automate the installation of upstream binaries.)

Take scoop for example, it simply consists of a collection of installation scripts https://github.com/lukesampson/scoop/tree/master/bucket for various apps, and the scoop binary itself which runs the scripts. The scripts are stored in JSON format in a central git repository, which makes it extremely easy for anyone to edit them and keep them up to date.

If you run scoop install python, all this does is:

  1. Check the central git repository for the latest python.json https://github.com/lukesampson/scoop/blob/master/bucket/python.json and download it.
  2. Download python from the upstream location defined in python.json.
  3. Install python with the options defined in python.json, and put it in the user's %PATH%.

You can imagine doing something like this with appimaged, or similar.

P.S. YAML is easier to read and write than JSON!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/631#issuecomment-361019878, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFdrrkUre7qx4ZS12uJmfCSXrmcHiWmks5tO6C2gaJpZM4Rlh6u .

shoogle commented 6 years ago

@azubieta, while I appreciate what you are doing, I personally would go about it a bit differently:

I think that there is a place for a software centre for AppImages (which is itself an AppImage) for people who want a convenient way to install them on (e.g.) a work machine that they don't have root privileges for. I personally would be happy with a command line program to do the same.

azubieta commented 6 years ago

Well my idea was to make a command line interface for the software center so you can search for the download links of your favorite appimages and pipe it with wget (or what ever you want). And yes we are about to make an appimage of it.

El 27 ene. 2018 4:53 PM, "Peter Jonas" notifications@github.com escribió:

@azubieta https://github.com/azubieta, while I appreciate what you are doing, I personally would go about it a bit differently:

I think that there is a place for a software centre for AppImages (which is itself an AppImage) for people who want a convenient way to install them on (e.g.) a work machine that they don't have root privileges for. I personally would be happy with a command line program to do the same.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/631#issuecomment-361022134, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFdrhFxMYwS0rIRqUq1mXRe7dhRLE6Dks5tO6jngaJpZM4Rlh6u .

probonopd commented 6 years ago

I would patch GNOME Software rather than making a new GUI

Not necessary, you could write an AppImage plugin for GNOME Software. Anyway, this would be a different project since NX Software Center is a Qt/KDE application.

simoniz0r commented 6 years ago

I personally would be happy with a command line program to do the same.

@shoogle You can check out appimagedl. It uses AppImageHub's feed.json to get information about available AppImages.

Right now, it only supports downloading AppImages from GitHub as those were the only links in feed.json, but I do plan on adding support for the Open Build Service links that have recently been added and other links in the future.

corppneq commented 6 years ago

@shoogle @azubieta That's sounds like something that is completely seperated from the mass downloader that I was asking for.

Would you be so kind and open a new issue so that I wont get constant notifications about an unrelated feature request?

TheAssassin commented 6 years ago

Closing now. This is clearly something for a third party project. Otherwise, please reopen in https://github.com/AppImage/appimage.github.io/.