Mass downloading of a list of AppImages #631
Comments
|
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. |
|
Life is to short for a manual installation. @TheAssassin That's the point. I don't want the AppImage in the backup. What I would like to do is:
The download could be done with wget but I still need to extract the urls |
|
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...
With AppImages, no installation is needed. Just copy the whole directory of AppImages from the source machine to the target machine, done. |
|
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. |
|
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? |
|
I guess I could do that myself. I am currently just a bit busy preparing for some exams. |
|
Agreed. Maybe I have a few minutes today and can come up with something. |
|
What Linux is missing (ironically) is a package installer like (Of course, Linux has plenty of package managers, like Take If you run
You can imagine doing something like this with P.S. YAML is easier to read and write than JSON! |
|
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
<#631 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABFdrrkUre7qx4ZS12uJmfCSXrmcHiWmks5tO6C2gaJpZM4Rlh6u>
.
|
|
@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. |
|
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 would have the software centre call a backend terminal program
- I would want to be able to install and use the backend without
installing the GUI
- I would patch GNOME Software rather than making a new GUI
- If making a new GUI, I would make it as an AppImage
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
<#631 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABFdrhFxMYwS0rIRqUq1mXRe7dhRLE6Dks5tO6jngaJpZM4Rlh6u>
.
|
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. |
@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. |
|
Closing now. This is clearly something for a third party project. Otherwise, please reopen in https://github.com/AppImage/appimage.github.io/. |
@pbeccard on https://twitter.com/pbeccard/status/954778344897249281:
Why not copy over the whole directory of AppImages (a big advantage of AppImages over installed applications imho)?
The text was updated successfully, but these errors were encountered: