Add a way to change the working directory

[DevilXD]

Closes #951.

[DevilXD]

I had to use a 3rd party site to upload this, since it's too big for a Github attachment.

Twitch.Drops.Miner.Linux.AppImage-x86_64.zip built from this PR, for testing: https://limewire.com/d/DSUDO#Ik3SgGh1vG

[DevilXD]

2nd build, slightly simplified code: https://limewire.com/d/GpFYg#ovHwwWlKjo

@WittyNameHere Please confirm this works for you. If so, I can merge this and close #951.

[WittyNameHere]

@WittyNameHere Please confirm this works for you. If so, I can merge this and close #951.

lgtm

[DevilXD]

As part of implementing the requested changes, it looks like I need to programmatically create the internal folder, that all of the files will end up in. One of the options for this operation is the mode parameter, which represents the RWX permissions of the created folder. The default is 0o777, which as as far as my limited Linux knowledge goes, essentially allows for all access by anyone.

Is this okay, or should I use something else here? From a random calculator I've found, it feels like 0o600 would be the correct one to use instead. That'd be RW for the user/owner, and nothing for everyone else.

[guihkx]

The vast majority of distros use 755 for directories and 644 for regular files, so I'd just use that.

[DevilXD]

Alright, did so. 3rd test build: https://limewire.com/d/Nsj8X#C4hgQBeMGm

[WittyNameHere]

I had an emergency of a personal nature occur, so I won't be able to test anything for a few days to a week. Thanks again for your work on this issue.

[DevilXD]

Hmm, I see.

@guihkx Does it look okay to you now?

[guihkx]

It looks fine, but thinking a bit more about it, I feel a bit conflicted about this change because I have $XDG_CONFIG_HOME set, and I also have two separate copies of TDM for using it with another Twitch account, and this makes it harder to keep them separated from one another...

Since the feature request specifically mentions an AppImage-specific feature, maybe we can limit this change to the AppImage build? By checking if this env is present:

TwitchDropsMiner/constants.py

Line 23 in 226cf3f

IS_APPIMAGE = "APPIMAGE" in os.environ and os.path.exists(os.environ["APPIMAGE"])

[DevilXD]

Hmm, right. I'm a little bit confused now though; can't you set environment variables on a per-process basis? I can't see how would --appimage-portable-config work otherwise, as if it'd set $XDG_CONFIG_HOME globally, it'd disrupt other applications running at the time, so it has to do it on a per-process basis, no?

I could limit this to AppImage builds only, yes. But that'd just solve it for the PyInstaller build, and the AppImage build would still be affected.

[guihkx]

can't you set environment variables on a per-process basis?

Yes, you can, but I don't think that's the issue. At least on my machine, all $XDG_*-related variables are defined globally for all processes by default: They're written in a .conf file in ~/.config/environment.d, which gets picked up at login by my display manager, which then sets them on all child processes (including TDM, of course).

And that's why it'd be much harder to have two instances of TDM running simultaneously if is implemented not just for the AppImage, because the cookies.jar file would be written to the same location in both instances, unless I make a script to change the path of $XDG_CONFIG_HOME just before I launch TDM, but that'd be too cumbersome.

--appimage-portable-config

All that launch option really does is to create a directory next to the AppImage called Twitch.Drops.Miner-x86_64.AppImage.config, and then it exits. And then when you launch TDM the next time, all config files for TDM will be written to that directory:

portable-appimage.mp4

And I think that's the desired outcome, but only for the AppImage. In my opinion, when running TDM from source and/or from the PyInstaller build, config files should be written next to the executable, like on Windows, even if $XDG_CONFIG_HOME is set.

[guihkx]

Or, we could just get rid of the $XDG_CONFIG_HOME check completely and instead detect if there's a directory named like this next to the AppImage (or PyInstaller executable): <ExecutableNameWithExtension>.config and use that as the WORKING_DIR.

My point is, I vote against writing to Linux config directories by default this late. But you run the show, so feel free to do whatever you want. :P

[DevilXD]

I want this change to be as frictionless as possible, but also don't want to complicate it too much. I need to think about this for a bit.

[WittyNameHere]

While I am not a programmer, my pipx library has given me a good number of Python tools and while this is the only one with a GUI, I don't know why you don't have a flag to select another profile. E.g. twitchdropsminer --cookies profileA/cookies.jar (or just whatever the profileA directory is called and the app searches for the cookie file there.) Command line flags are pretty advanced stuff for Windows users, true, but I consider farming drops on multiple accounts a power user thing anyway. The only question then is if the app is programmed to start a second instance if invoked while running.

One can then just create a script, whether a Linux shells script, PowerShell, or even the ancient .BAT file from DOS, to launch it however many times with however many configurations. Again, yes it's a bit of a power user thing, but you could also have multiple copies of the program with a single profile if you really dislike the Terminal.

I realize this is quite off the subject of the original issue, it was just a thought. For what it's worth, I am totally fine with the AppImage build alone using the apec's feature to see a config folder on the same directory and use that

[DevilXD]

The problem with multi-instance mining is that the miner isn't designed for it. Even running a 2nd instance already violates the websocket connection limits specified by Twitch's dev guidelines. The miner's GQL rate limiter is tuned to work for a single instance too. All of this is IP based, so unless you're running the instances through some kind of IP-altering proxy, you're just going to end up with all kinds of troubles using it. There's no point building "profiles" into this thing, if it's all not going to work anyway. And if someone smarter than me would like to go and study this route, the code is open-source - just please don't try to involve me into it.

I'm trying to support your portable AppImage use-case here, not trying to discuss #31 again. Please keep that in mind. As I've said, I want this to work without disrupting the existing setups, and there's a few solutions, so I need to think about it a bit.

[DevilXD]

Sorry it took so long, I was taken away by IRL events for a moment.

I thought about it for a while, and figured out that doing anything with the $XDG_CONFIG_HOME env var is a no-go, because some systems may have it already defined. I've went ahead and implemented it the way @guihkx suggested in #953 (comment), with just the config folder detection by name. I don't know if I did it correctly though, so if someone could give it a quick test, that'd be great.

New link for testing: https://limewire.com/d/fBAui#hfeAfF5Tky

[guihkx]

Tested and working.

IMO, this remains the best approach at implementing just #951, without introducing breakage to other set ups.