openSUSE / opi

OBS Package Installer (CLI)
GNU General Public License v3.0
244 stars 22 forks source link

Cannot search. "UnboundLocalError: local variable 'Project' referenced before before assignment" #88

Closed averyfreeman closed 2 years ago

averyfreeman commented 2 years ago

Sysinfo:

opi version 2.4.2

MicroOS 20220113 in a VM in virt-manager on laptop running Tumbleweed

opi alone runs fine, and you can see I got the version string from it.

Attempted:

opi dfc

Expected:

Search results for dfc package from OBS.

Actual result:

Stack trace:

Traceback (most recent call last):
File "usr/bin/opi", line 69, in <module>
 binaries.extend(opi.search_published_binary('openSUSE, args.query))
File "/usr/lib/python3.8/site-packages/opi/__init__.py", line 155, in search_published_binary
  distribution = get_distribution(prefix=(obs_instance != 'openSUSE'))
File "/usr/lib/python3.8/site-packages/opi/__init__py", line 61, in get_distrbution
  return project
UnboundLocalError: local variable 'project' referenced before assignment

I apologize I am not able to copy from the VM right now, so if that is inaccurate it's because I typed it all out manually

Other notes:

I've gotten a similar error in Tumbleweed which I had attributed to OBS having too much latency and timing out, because when I'd run it later it would work fine, but it's happening 100% of the time in this MicroOS VM.

Let me know if you have any questions. Thanks

asdil12 commented 2 years ago

The problem seems to be in https://github.com/openSUSE/opi/blob/master/opi/__init__.py#L52-L62:

This is the content of /etc/os-release on a tumbleweed based MicroOS:

NAME="openSUSE MicroOS"
# VERSION="20220122"
ID="opensuse-microos"
ID_LIKE="suse opensuse opensuse-tumbleweed"
VERSION_ID="20220122"
PRETTY_NAME="openSUSE MicroOS"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:microos:20220122"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS"
LOGO="distributor-logo-MicroOS"

If I would update the code like this:

    name = os_release['NAME']
    version = os_release.get('VERSION') # VERSION is not set for TW
-   if name == 'openSUSE Tumbleweed':
+   if name == 'openSUSE Tumbleweed' or name == 'openSUSE MicroOS':
        project = 'openSUSE:Factory'

... this should actually work, but it could create issues with Leap micross.

Let's see how the /etc/os-release looks on a leap 15.3 microos:

NAME="openSUSE Leap Micro"
VERSION="5.1"
ID="opensuse-leap-micro"
ID_LIKE="suse opensuse opensuse-leap suse-microos"
VERSION_ID="5.1"
PRETTY_NAME="openSUSE Leap Micro 5.1"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap-micro:5.1"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

So that means that I could differentiate between tumbleweed microos and leap microos, but I don't know how I can find out, that MicroOS 5.1 is based on leap 15.3.

So I guess I will ignore leap microos for now and apply the fix from above.

Note that obviously as MicroOS is a transactional server, it would only make ever sense to run opi within transactional-update shell.

asdil12 commented 2 years ago

https://github.com/openSUSE/opi/commit/c7824d4118c220058c9e98c45e9e4c974885afae

asdil12 commented 2 years ago

https://build.opensuse.org/request/show/948388

averyfreeman commented 2 years ago

@asdil12 thank you for the commit. I don't think MicroOS Leap is destined to get beyond "experimental" release, so if you had to choose one, focusing on Tumbleweed version would make more sense from a market share standpoint.

BTW transactional-update has been deprecated, command is unavailable. I don't think it's reflected in official docs. New process is:

tukit execute bash << zypper commands >> reboot

This worked fine for me, I had less luck with pkcon. Found some info here if you're interested: https://opensuse.github.io/openSUSE-docs-revamped-temp/microos_getting_started/