No real need to be concerned, the script does pretty much exactly the same thing as manually going to the site and clicking the download links, except with more convenience. And since it's open source (and simple enough) you can see for yourself exactly what it does. :)

You're pretty much correct. You should import to establish the initial setup (possibly making a manual backup of your original setup first), backup is to make a copy of an existing gogrepo hierachy. Be aware that if your collection is large verification can take a long time on the first run. I added not reverifying an eisting file a few of years ago after it took more than a day to verify my files. Though part of that is because this was before I added pre-allocation and the files were heavily fragmented.

In the past I wanted to try using simlinks to create my own folders & naming structure, but gogrepo didn't seem able to recognize them.
But maybe such solution would be too complex to maintain anyway.
Also, MS seems to have broken some compatibility with Classic Shell for simlinks in Win7's tree-view pane, so that's another annoyance to consider.

Thanks for all the feedback. I began the process of creating the new archive: generating the manifest alone took around an hour (i was expecting alot more from an old post that mentioned taking around 8-9 hours).
Currently it's importing the files to the new location. I noticed it's only importing the main installer, not any of the extras when they exist. It will mean some extra downloads, but it's a small price to pay for the automation.

Yeah, gogrepo has been optimized a lot since then, expecially thanks to Kalanyr.
Btw the script is capable to download extras, maybe you're using some wrong parameter?
(I prefer to keep them separated btw)

So, let's see if I get this right.

a) The manifest is merely the detailed list of your current GOG library. It holds no other information (such as : which file has already been downloaded, or which file is currently present in the local folder).

b) Only the "download" command actually imports files from gog.com. It downloads either the full content of the manifest, or the title specified by a gog file name. [But it does check if the content is already in the folders before re-downloading it, right ?]

So :

c) The only way to manage categories of games to download is... by managing the content of the manifest ? And its content options are : "all the games", only "the updated games", or "only the new games" ?

No way, for instance, to keep updating only the already downloaded games ?

That's severely limited, but I suppose that once someone decides to use it to download the whole library to one place, it allows to keep the library updated without ever visiting this website again. So, there's that in compensation.

I don't mean the download function, that should work ok from the test i did, i mean the import function from a) location to b) location, so far its only copying the installers and nothing else, the backup function from a) to b) would do it, but would also copy stuff that the script doesnt need like the !temp folder i have in the old archive location. But it's not a big problem, and it will only concern this first run.
From what i understand the default behaviour is only download new stuff, if the files are the same on the archive it will skip them, but it will not delete the outdated installers. There are some functions for that like clean and trash, and there are alot of variables that can be used for each command. The readme is very detailed, even tough one doesnt need to use all the options.

Maybe one can have multiple manifests depending on archive location, but thats abit out of my league.

It's generally better to have one manifest and use the os / lang / extra filters to split things for those. You can use -ids and -skipids to download only specific games or to skip specific games. At some point I'll probably implement regex matching to allow better filtering of games.

(To be clear this is about the dev build of GOGrepoc ( https://github.com/Kalanyr/gogrepoc/tree/dev ) as is the post I'm responding too. The original doesn't have the trash command)

Before performing the download, you can of course manually copy any missing files that the import missed and you think should be there to the games' subfolders. Then the download function will notice that the files are already there (I think it checks the filename and size) and will skip downloading them. Of course depends on the number of games whether doing this manually (in order to prevent unnecessary extra downloads) makes sense.

The extras go to the same subdirectory as the main game installer files, not into any separate subdirectory or such.

Happy to report that the whole transition process is mostly finished without issues. Even prepared afew batch files to avoid typing mistakes.
Looking at the process as a whole, i should have changed long ago to gogrepo. It really is a timesaver and more efficient, compared to any of the other options. Many thanks to both the original creator and Kalanyr.

Well done. And yeah, Gogrepo is great!

By the way, it's a shame that Gog has never offered an official tool to properly manage standalones (and they even killed the Downloader).
Third party tools can stop working and stop being maintaned at any time. Luckly, Gogrepo is on Github and Kalanyr's main version is pretty stable.

So can official tools, such as GOG Downloader. ;)

It has both benefits and drawbacks that e.g. gogrepo is third-party (and open source):

+ If someone abandon's the development and maintenance, someone else can pick it up.

+ People can even make their own versions of the tool, making it include features that they want.

+ Overall I think it is easier to get feature requests implemented in an open-source third-party tool, than an official one.

+ The user-made tool can be lower-profile without a GUI or such, which can make the tool more cross-platform, like is the case with gogrepo. I can run gogrepo on e.g. my Raspberry Pi, while I couldn't run e.g. Galaxy or GOG Downloader on it, as they are Windows-only and x86-only. Gogrepo doesn't care what OS or CPU architecture I am using, it just works.

The only real reason why I might prefer GOG coming up with a similar official (mass-)downloader tool would be that they could implement e.g. peer-to-peer support to the tool properly. Properly here meaning that it lets you download with p2p only games that you have purchased. I presume that in e.g. Bittorrent terms, GOG would act as the tracker server which decides whether you can initiate a download for a certain file from other GOG users.

You're kinda explaining points that I already summarized in "Luckly, Gogrepo is on Github". :P
But I get what you mean.

Btw, another worry with unofficial tools is that Gog could decide to block them all, if they get too (ab)used (e.g: "From now on, we'll only allow downloads via browser or Galaxy.").

And a torrent solution wouldn't be bad, with good upload requirements & limits. But gogrepo is way more than just a mass-downloader.

First off big thanks to the author. Obvious labor of love that benefits us all.

This may have been mentioned somewhere else in the 100+ pages but wanted to share that Python 2.7.9 build for Windows is the only 2.7 build that comes bundled with Pip and you apparently cannot install Pip easily for older versions of 2.7 using normal methods due to SSL/TLS issues (upgrade to latest Python, it says). Hopefully this saves someone some trouble down the road.

I actually installed this onto a Windows 8.1 VM (seems much snappier than 10) and download everything to a folder shared through Virtualbox. Works great

I've decided to start deprecating Python 2 support.

There will probably be 2 more major releases that support it. The one I'm currently working on and 1 last one to get it into a state that I'm comfortable leaving as the last Python 2 supporting version. At some point after that I'll remove the Python 2 support from the code and then refactor things to take advantage of things not available in Python 2.

If you currently use Python 2 and can't move to Python 3, what are the features you most want added / bugs you want fixed / conveniences / etc ?