-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open discussion about the future of the image #159
Comments
It is time to say goodbye to Python 2 for sure. I see little to no reason to maintain older rtorrent versions, looking at linuxserver/deluge they only maintain the last version (correct me if I am wrong). If anyone wants to use an older version they are welcome to pull an older image (as I did for deluge). It just takes too much developer bandwidth (and money) to upkeep multiple versions running, even with CI/CD pipelines. |
I personally would like to be able to use the pyro utilities, but I don't mind pinning to an older Docker image in the hopes they work on Python3 support (though I am not holding my breath). I don't suppose it's practical to have both Python2 and Python3 installed (with the relevant version suffixes)? This is how I've handled analogous situations in the past, but I am not familiar enough with the internals of the projects relevant to this discussion to determine if that is practical to accomplish. |
My 2 cents, I use this image specifically for the rtcontrol features, which are pretty unparalleled in usefulness for managing thousands of torrents. |
I completely rebased this repo to use rutorrent-docker image. Now it runs on Alpine 3.12 too. As I have made the decision to delete the other branches, it is easier to maintain now both python versions. For the moment I will continue to include pyrocore. Thank you everyone for your opinion! |
|
Hi everyone!
I am making tests to give this image support on Alpine 3.12, as it was released a few months ago.
This time, as this image is used by thousands of users, I think that is better to open a new discussion so everyone gives their opinion about the current situation I would like to solve.
Rtorrent 0.9.8 is supported by the vast majority of trackers, so I am start thinking that maintaining older versions is not needed anymore. If you take a look at Jenkinsfile and Dockerfile, older versions of rtorrent doesn't run on latest Alpine versions, so I need to make a lot of "awful" patches using conditionals depending on the version of rtorrent in order to build the image accordingly. This things complicates a lot with each Alpine version that is released. In Alpine 3.12, things get worse. As stated on its Release notes, this version changes python support. Python v2 went out of support on January 2020, so the community behind Alpine has taken the decision to start the process to remove it. In Alpine 3.12, pip is not included anymore on python package, so I need to change python installation in the Dockerfile for different image versions, so it would add more complexity and more "patches" are needed so I can continue building images for every rtorrent version. I think this wouldn't make sense anymore.
In my opinion, since this moment I think the best option is to take out of support every rtorrent version older than 0.9.8. This version would run perfectly on Alpine 3.12, so this way I can center only on this version and it would be much easier for me to improve it much more frequently, as testing only one version would be really easy.
Another important thing if I take this decision is what to make with pyrocore. Right now, pyrocore only supports Python 2. There is an issue open on pyrocore repository since more than 4 years ago, and right now it continues to be supported only on Python 2. I am convinced that it's time to say goodbye to Python 2. When I update the image to Alpine 3.12, pyrocore will need to be removed. This is something I don't use, so there will be no problem for me, but I would like to know how many people use it to evaluate if this would be a problem.
Please, your opinion is needed to see what is the best way to proceed with these.
Another thing I am thinking, but only in case of supporting only the latest rtorrent version, is unifying rutorrent-flood-docker and rutorrent-docker repositories. Using an environment variable, we can select to start flood or not. The only concern about this is that flood image is bigger than the one without it, so I don't know if you think this could be a good idea.
Thank you anyone.
The text was updated successfully, but these errors were encountered: