Add Command Line Interface mode #173
Conversation
There was a problem hiding this comment.
Hello there o/
This is an interesting PR, mostly because I never thought about actually transforming this application into a command line interface, figuring out it'd be really hard to "uncouple" the GUI code from the application. Turns out it's not that hard, if one just makes it so that most GUI calls end up not doing anything.
That being said, there's some more work needed on this, per review comments. There's also my unchanged stance on the whole idea of this project having a CLI interface or being in any way easier to use in a display-less or account-link-less environment (server), here: #84
I'd need a really good and convincing reason to merge this in, even if all of the review feedback would be addressed. Why exactly is this needed for a personal, single-account utility program like this one?
|
Just from my personal perspective: I'm a user in China (UTC+8 Time zone), where some Twitch live streaming in place like Europe starts at an unfriendly local time (like at mid-night) here. I don't want to keep my laptop on and idling for a whole night, but sometimes if I don't it's hard to get the full drop rewards. (In particular, the game I'm playing now, "Tom Clancy's Rainbow Six Siege", requires 4 hours' watching to get a single drop. And sometimes drops are even only enable for official live rooms, so I have to follow the official campaign schedule to get the full rewards.) In this case, the best solution is to run this program on my VPS (and it's display-less). That's the initial reason why I wrote this fork. It might be more convenient of allowing it to run on server non-stop, even for personal use. Also this PR doesn't cancel the limit of linked accounts, maybe still be able to prevent abuse to some degree (though adding CLI mode still facilitates for multi-instance mining and profiting, of course). Anyway, I can understand your considerations if you decide to refuse adding this feature eventually. And thanks for your review comments <3 |
|
Honestly this is 1 of 2 things I really hope gets implemented.. the second hopefully being a lot easier once this gets implemented and that would be getting this to run in docker. |
|
@JourneyOver You should check out the project goals: https://github.com/DevilXD/TwitchDropsMiner#project-goals This PR isn't getting merged, because it leads to abuse. It goes as far as me considering pulling down the entire project, but it hasn't been bad enough yet to do so. At least as far as I'm aware. |
|
I honestly have no idea, why do you consider using it through cli to be "abuse". I'm in a situation, where there's a surprise campaign running, but out of like 50 enabled channels there's only one live and I'm not sure if I'd be able to get all drops before campaign ends, especially if that channel goes offline. I'd like to leave this program running overnight, but my gaming pc's fans are quite loud even when idling, so I'd prefer not to have to sleep in a room with pc on. I could run it on a raspberry pi that I own, which has passive cooling and is completely silent, but it's not plugged to any monitors, so it boots in headless mode and it would be a lot of hassle to boot it in a way where I can connect via vitual desktop. So I'm failing to understand your thought process. I could run it 24/7 in a background on my pc. I could run it 24/7 on any remote server with remote desktop protocol. But the convenience of being able to run it on my own machine that happens to boot without gui is just too much, and you would consider this "abuse"? |
|
@ignis05 The reasoning behind it is already explained in the Project Goals section, a link to which you seem to have intentionally ignored. There are links to issues within said section, that exactly explain why I really don't want this project to be possible to run in headless mode. I wanted to do it at the beginning, but I don't want to now. It only leads to abuse and nothing else. I don't want thousands of instances running on some remote server, for profit purposes. In case you still can't understand it - this is a hobby project. I'm a one-man development team, currently taken away by a 6/10 work cycle since a month ago, and for the next month or so. I don't have the time to resolve the existing issues, yet alone design a foolproof system that won't end up crashing and sending the miner into an endless restart loop. Even if I wanted to, this project is far from being ready to become "headless" in a sense where you can "set and forget" it. In other words, this project isn't ready for headless, and I'm not doing anything to help it, because I don't have the time for it, and it only leads to abuse, so why bother. Due to abusers, we can't have nice things - this is the sad truth of it. For more abuse examples, see #84, also linked in the project goals section: https://github.com/DevilXD/TwitchDropsMiner#project-goals |
|
I did not ignore anything, it's just that the project goals don't really mention anything other than it being possible to "abuse" and being at the bottom of the priority list. While on this pr you simply said Like I said, it's not like running it in its current state as a 24/7 farm is impossible, it's just a bit more tedious to set up. I understand your reasons for not wanting your personal project to be used against your will, even if I disagree with the sentiment that automatically farming drops with like 60% uptime on a personal pc is great, but doing the same thing on a headless server with better uptime or including farming channel points and drops for unlinked accounts is taking it too far and straight up abuse. But I guess when it comes to morality, everyone draws the line one step ahead of where they stand. You asked earlier in the thread in regard to the headless mode, But while I might disagree on what counts as abuse, I understand that in the end, this is your project, and you are free to do anything you want with it. I appreciate the unpaid work you've already put into this and that you chose to share it with everyone, and I wish you the best, regardless of what you choose to do with this pr. |
|
Personally, I use it on a headless Linux server, as I described in #17. Once you figure it out, it really requires little to no effort already. I even have a script that can updated to latest Master (.bat), so I could have it be 0 maintenance if I combined those. The reason for doing this is partly because of #80 and partly so that I don't have to have my PC running 24/7 (for drops that are only one stream from one channel during a specific event), which spares additional wear on my PC and saves power. Given it's really easy to implement headless, whether by finding this pull request, the docker pull request, or using Xvfb as I did, any server farm described in #84 (comment) could easily be deployed anyways. I think it's reasonable to assume, that anyone seeking profit would be willing to put the extra bit of effort in and thus it's only really inconveniencing ethical users, who might not have the knowledge, time or incentive to implement the bot in this way. |
|
This project started as a small, personal script, that I eventually had an idea of sharing with others. From the very beginning of this project, the idea was to have a console application, capable of being deployed on a remote server and mostly forgotten about. As a personal bot of sorts, it'd take care of only a single Twitch account, and that's it. A simple, helpful tool, reliving you of having to keep track of which channels are online, changing the channel when the watching one goes offline, and having to be there on time to claim the drop. All of this info is still present in the However, some people didn't understand what this project is for. They wanted to "go big" - and have massive farms of hundreds, thousands of accounts, all mining drops for personal profit. I've been literally involuntarily dragged into a "deal" between two people, where one was selling a "server with 10 instances on it" to the other, where the other person was contacting me and demanding to know when I'd fix a critical-at-the-time issue (#68), preventing the miner from claiming the drops. It changed me. I no longer want to make it possible to run this on a remote server, and this is the least I can do to try and limit the misuse of this project. Yes, it makes it "inconvenient" for people who would want to do that, but as I cannot control how many instances you're going to run on that servers of yours, I cannot allow for it. I do not support misuse and abuse - and if it's going to continue, this project will simply be discontinued entirely. I'm not going to waste my time for the profit of others, since again - this isn't the purpose of this project.
There are other projects like this out there, that make it much easier to deploy. I don't get why someone cannot just use that one instead. As far as my own personal experience goes, "putting in effort" is enough of a deterrent to limit the abuse on it's own. There's no way to stop it, unfortunately, as any open-source project can be repurposed to bypass it's limitations, with enough effort put in. It's been doing a good enough job, ever since "the change" happened, and I didn't head from anyone trying to make a giant farm since.
Good. Again, being able to run this on a remote server isn't the purpose of this project - not anymore. Nobody forces anyone to use this thing either. If one doesn't find it suitable for their purpose - they shouldn't use it. Simple. If anyone would like to have a miner they can deploy on a server, as I said before, there are other, more suitable projects out there, that can do exactly that, Please use that one instead. |
|
While I disagree, it's a matter of opinion at this point. At the end of the day, I'm just grateful you publish your work for free, making it available to all of us. Thank you. <3 |
Add support for pure Command Line Interface, by reimplementing
GUIManagerasCLIManager, for the case running on server without GUI Desktop as a 24*7-hour bot.In the CLI mode, I only implemented the display of a few core information, because many functions are probably not required when it is simply running as a bot on a server (and it requires less work). Configuration through the user interface is not supported, so you need to edit
settings.jsonmanually (should not be a problem for someone using command line).Logging in is supported. The user just needs to open the link in their browser (not required to be on the same machine as the server) and enter the code.
Usage
Add
--cliargument to launch in CLI mode.Screenshot
It works fine on my Ubuntu server:
Help wanted: In
main.py, to make it works with CLI mode, I have to move the parser to before creating the window temporarily, so that works in the following flow:--cliflag is set (or else an error will occur if it tries to create a window in a non-GUI environment)In the current implementation, an error will occur if the parser output something to the message box. A better method is needed, maybe direct the parser output to the console? I am not sure whether it will bring any additional problems, so I did not fix it.