"You are running Setuptools on Python 2, which is no longer supported"

Troubleshooting
1

Has anybody else seen this error in their logs?

I tried searching the forums and didn’t find anything.

The full output is:

/opt/rockstor/eggs/setuptools-45.1.0-py2.7.egg/pkg_resources/py2_warn.py:22: UserWarning: Setuptools will stop working on Python 2

You are running Setuptools on Python 2, which is no longer
supported and

SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release (no sooner than 2020-04-20).
Please ensure you are installing
Setuptools using pip 9.x or later or pin to setuptools<45
in your environment.
If you have done those things and are still encountering
this message, please comment in
https://github.com/pypa/setuptools/issues/1458
about the steps that led to this unsupported combination.

sys.version_info < (3,) and warnings.warn(pre + “" * 60 + msg + "” * 60)

This might be new since 3.9.2-52, since if first showed up during a btrfs snapshot on 29/01/2020. the same day of the rockstor update.

2

@mattyvau Hello again.

Yes we have quite a substantial amount of technical debt and Python2 is one a major element of this. But the build system we have used for the entire projects history is I believe now no longer maintained and I think is python2 only so we have to find and implement an alternative. I’m hoping to get our Stable openSUSE version out first with near enough feature parity to our CentOS variant so we can at least get folks onto an upstream supported btrfs before we tackle these fairly massive system wide changes in the testing channel as that is what it’s for.

Any contributions you have on our options are welcome. I’m open to all suggestions but these will be massive changes across the entire project so stuff will likely be broken for a while. Another closely related issue is our Django version. We are hoping to jump to much later versions of both Python and Django to head off such things happening again in the future.

Do you run a source install by chance, and if so on which disto?

We have begun the move to Python3 but only in baby steps, ie importing the future library etc. But this is going to be a painful exercise that will likely have to be my main and possibly only project for quite a while. And Django updates are also frought with difficulty. But again I want to be able to offer folks an upstream supported btrfs prior to this with at least workable openSUSE builds.

We also now have issues with building in Tumbleweed so if you are building from source it would be a benefit to have some input on that front as I’m quite keen of offering both as we go forward. In that case I’m pretty sure it’s down to a Python update that breaks compatibility with one of our older libraries so I’m hoping a jump in that library will sort this. But again many of these dependencies, such as the nieve dependabot is always suggesting would simply break if we jump without first upgrading everything else, such as the Python2 to Python3 move and it’s consequent Django move. We certainly have our work cut out so do chip in if you have the time / expertise. Next most pressing issue it the Tumbleweed failure to build. This is important as it has been a really usefull indicator of what’s coming down the line as it were with Leap 15.x. We had for example a yum failure first, very recently, in Tumbleweed and that prompted us to move to dnf-yum. This same move was then shortly mirrored in Leap15.1. So I’m super pleased to have such early signals and the next one appears to be why we now fail to build in Tumbleweed.

Thanks for the heads up and yes we have seen a few messages of this type for quite a while but we have also had really old versions of btrfs for quite a while. So getting a working openSUSE build that can server our supporters/users while we grapple with the many ageing dependencies in the recently re-launched, openSUSE only, testing channel would be great. But we can’t do that until we have a more functional release in the testing channel so it can be promoted to the stable channel. Freeing up the testing channel for these bigger and more far reaching changes. I.e. updating everything and moving from a series of bolt on technologies to build in stuff, ie like Pythons async await and Some async stuff in Django 3 for example, but these newer ‘native’ technologies just didn’t exist at the time the project was started. And we haven’t had the resources to maintain dependency / core technology updates while doing our own development / bug fixes. So yes if you or others have the time to address these issues then super, I’m up for reviewing pull requests as they arrive, but we also have to get folks onto something usable in Stable for openSUSE before we load up the testing channel with all these changes.

Hope that helps, and thanks again for the heads up.

2 Likes
3

Just to add that I am also seeing these now in my emails - from /opt/rockstor//bin/st-pool-scrub and /opt/rockstor/bin/st-snapshot cron jobs. I am not overly concerned for now, as these are warnings / nags from python 2.x .

1 Like
4

Hi @phillxnet

Sorry for the delayed reply.

Yes I figured the warning was due to the python2 EOL coming up and expected you would be aware of the python2 issue in this part of the system. Wanted to make sure though, just in case. I forgot to mention that, as per Barry’s reply, I first noticed this as an email notification from a snapshot scheduled task, and it seems they all do that now.

My rockstor is still on the stable (with subscription) option and I don’t currently have much in the way of spare hardware where I could do testing. I’m planning to re-purpose an old desktop to be a server that can be experimented with, so I’m open to trying some suggestions if I can ever put some more drives in that. Cloning my current install sans data might mean I can test (break) stuff to try migrations if required.

Other than that, my expertise level is probably closer to newbie than pro despite exclusively using Linux for over a decade. I can usually manage to build from source when following a good guide.

Otherwise, I’ll keep following the development of the OpenSUSE branch in the forums and be happy to try upgrades when testing binaries are available and I have some hardware.

As for this particular error, I think so long as people know their current system isn’t broken as such, it will be fine until the new branch in available.

2 Likes
5

I am too seeing this warning message on my stable channel image. For completeness, here is a link to the Python Software Foundation that I stumbled across while researching this:

I assume, while still being on the Centos version it will “always” be a warning, despite the sunsetting, but post-April there won’t be any more security fixes (well, and no bug fixes, which is probably irrelevant for the Rockstor distribution at this point)?

Would love to help the transition there, but I’m afraid, my “skills” would probably harm more than improve the situation.

2 Likes
6

@mattyvau, @Bazza, and @Hooverdan.

I’ve finally managed to put some time into this one. As it happens, due to more recent preparation on the rpm build systems side of things, our openSUSE rpms are not affected by this issue. Mainly as they resource and have as a dependency the site-package (system installed) python2-setuptools. Where as our CentOS rpm builds do not have this dependency and thus end up pulling in, via buildout and it’s use of initially an old setuptools to get ez-setup so the setuptools can ‘self-update’. And the core of the issue is that it’s tricky to pin within this convoluted, self-updating process. But if the latter stages (used in building the rpm) of this same process finds a site-package setuptools update for python2 that is newer than the initially downloaded 33.1.1 version required to run ez_setup.py then it doesn’t grab that days version from PyPi; such as is happening in our CentOS build.

Proper fix is to move to Python 3 of course and that process is underway, but slowly. However once we have our ‘Built on openSUSE’ Stable channel rpm out we can focus on addressing this large technical debt in our testing channel. The Buildout project themselves, and specifically their bootstrap part that we use, have been moving to and testing against Python3 versions for some time and I believe are under way with incorporating the depricated elements they need from older setuptools so hopefully we can leverage their work, and contribute back in necessary, as we move our entire source and rpm build system and all our own source and dependencies over to Python 3.

Incidentally the easiest re-producer I’ve found is our emergency rock-on db/image cleaner script:

Leap15.2 beta

leap15-2:~ # /opt/rockstor/bin/delete-rockon                                                                                        
Delete metadata, containers and images of a Rock-on                                                                                 
        Usage: /opt/rockstor/bin/delete-rockon <rockon name>

Current CentOS rpm:

[root@rockprod ~]# /opt/rockstor/bin/delete-rockon
/opt/rockstor/eggs/setuptools-46.1.3-py2.7.egg/pkg_resources/py2_warn.py:21: UserWarning: Setuptools will stop working on Python 2
************************************************************
You are running Setuptools on Python 2, which is no longer
supported and
>>> SETUPTOOLS WILL STOP WORKING <<<
in a subsequent release (no sooner than 2020-04-20).
Please ensure you are installing
Setuptools using pip 9.x or later or pin to `setuptools<45`
in your environment.
If you have done those things and are still encountering
this message, please follow up at
https://bit.ly/setuptools-py2-warning.
************************************************************
  sys.version_info < (3,) and warnings.warn(pre + "*" * 60 + msg + "*" * 60)
Delete metadata, containers and images of a Rock-on
        Usage: /opt/rockstor/bin/delete-rockon <rockon name>

But here’s another wrinkle. The python2-setuptools available in both Leap15.1 and Leap15.2beta do present as an update to the initially downloaded by buildout bootstrap.py 33.1.1 update:

Leap15.1

leap15-1:~ # rpm -qa | grep setuptools
python3-setuptools-40.5.0-lp151.1.1.noarch
python2-setuptools-40.5.0-lp151.1.1.noarch
leap15-1:~ # ls -la /opt/rockstor/develop-eggs/
total 8
drwxr-xr-x 1 root root  72 Apr 20 00:13 .
drwxr-xr-x 1 root root 362 Apr 20 00:13 ..
-rw-r--r-- 1 root root  33 Apr 19 23:49 rockstor.egg-link
-rw-r--r-- 1 root root  32 Apr 19 23:49 setuptools.egg-link
leap15-1:~ # cat /opt/rockstor/develop-eggs/setuptools.egg-link
/usr/lib/python2.7/site-packages

Leap15.2beta

leap15-2:~ # rpm -qa | grep setuptools
python3-setuptools-40.5.0-lp152.2.3.noarch
python2-setuptools-40.5.0-lp152.2.3.noarch
leap15-2:~ # ls -la /opt/rockstor/develop-eggs/
total 8
drwxr-xr-x 1 root root  72 Apr 19 23:50 .
drwxr-xr-x 1 root root 362 Apr 19 23:50 ..
-rw-r--r-- 1 root root  33 Apr 19 23:49 rockstor.egg-link
-rw-r--r-- 1 root root  32 Apr 19 23:49 setuptools.egg-link
leap15-2:~ # cat /opt/rockstor/develop-eggs/setuptools.egg-link
/usr/lib/python2.7/site-packages

Where as our CentOS rpm build without a site install of python-setuptools (it’s name in CentOS) ends up pulling in the very latest egg as per the

which is now, in 3.9.2-57 rpm even newer.

However the site package (distro provided) for CentOS is:

[root@rockprod rockstor-dev]# rpm -qa | grep setuptools
python-setuptools-0.9.8-7.el7.noarch
python3-setuptools-39.2.0-10.el7.noarch

And it looks like in this case our tower of tools/dependencies build system chooses upgrade to the latest from Pypi anyway. So what works for us in our ‘Built on openSUSE’ variants does not serve similarly in our CentOS build. This looks to be due to the extremely old version of python-setuptools in CentOS.

During the build of all the openSUSE variants the plain source and the production build (used in creating the rpm) both stick with this 3.1.1 egg up until late in the build process, but some build element ends up substituting the site-package in our openSUSE builds, which works for us, and the overly new and shiny in the CentOS bilds, which does not work for us; or soon won’t anyway.

I am currently investigating our options on this one.

I would obviously prefer to use the distro variant as it’s build in concert with the exact python version we run under (the distro python2 variant for now).

So this has turned out to be quite a deep problem and is, as indicated all around, just another call to our technical debt. We are already using the latest version of six across all distro rpms since 3.9.2-53 so that should assist with our in-progress move to Python 3. And again this is pulled down during our build except for in the cases of Leap15.2beta & Tumbleweed rpm builds as they have sufficiently new enough packages to not have to include them in the rpm itself.

So just thought I’d use this thread to document my findings / progress thus far on this issue and the direction I’m trying to take is to depend upon as many distro python packages as possible as they are build together by the upstream distro maintainer and so are more likely to play nicely together. But as detailed above this is getting a little tricky. So this technical debt must be at least part our next focus, once we have feature parity, or near enough, in our ‘Built on openSUSE’ offerings. And I’d say we are actually pretty close. Plus we have to pick our battles here also.

Hope that helps.

3 Likes
7

Just wanted to pop in and say that I attempted a fresh install on Tumbleweed today, and couldn’t due to python2 packages not being available.

Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides python2-distro needed by rockstor-3.9.2-59.x86_64
 Solution 1: do not install rockstor-3.9.2-59.x86_64
 Solution 2: break rockstor-3.9.2-59.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/c/d/?] (c):
8

@StephenBrown2

Yes, I’m afraid the Tumbleweed rpms are build on a system that has the now deprecated and removed python 2 packages, but still required by Rockstor, grandfathered in. Our next main task, after the ‘Built on openSUSE’ relaunch is to deal with the rest of our technical debt starting with updating our now old Django / Python 2 stack and all of it’s dependencies so that we no longer depend on Python 2. This unfortunately is a large task that we can’t properly start until we have folks onto an upstream supported btrfs stack. And our ‘Built on openSUSE’ Leap effort is just that.

If you want to try these Tumbleweed RPM’s, and it would help others also, you will need to find a repository that provides the missing python2 libs still required by our rpm and the core source they are build from.

Another missing dependency is python2-requests. There may be others but as you find and install the missing ones the others will pop us as also missing.

But on the Leap 15.2 side of thinks, our current release target distro, these libraries are still part of the main distribution and will be for that distributions life time. In this regard we can/do use Tumbleweed as our view of the future and it’s been really useful/informative in that regard.

So in short if you can find the missing Python 2 librarie packages then the Tumbleweed rpm we make should work, but our main focus is on the Leap 15.2 target which is currently in release candidate phase. There is always the Leap 15.1 rpms as well of course, but as Leap 15.2 settles in we may no longer build for 15.1 depending on how things go.

Let us know if you find a legitimate repo hosting those missing python2 dependencies, ideally an OBS one, and I can add it to the instructions for folks wanting to dabble in the Tumbleweed futures.

Thanks for your feedback on this one.

1 Like