sudo eopkg install --reinstall ypkg ?

If that doesn't work, you may have a broken package somewhere else affecting this. Alternatively, you might be using a different python than the system python by accident if you use virtualenvs, anaconda, etc.

I see, so here's what I did:
1- reinstalled ypkg (eopkg it --reinstall ypkg)
2- made sure I'm not in a virtualenv, and that my python is the latest one from repos:

 ~ ; eopkg sf `which python`
Searching for /usr/bin/python
Package python has file /usr/bin/python

3- made sure I'm not inside any weird environment or anything like that

Then I tried again, ran ypkg and got the same traceback :(

Can you check your environment for any python-related variables?

env | grep -i python

If the reinstall didn't fix it, I have to assume your python search paths are mixed up.

there aren't any defined variables with that check (I think that's the normal?)
I also checked for ypkg's integrity with eopkg check
Dirs like /usr/lib/python2.7/site-packages/ypkg2 exist

Just an extra check that the search path is correct, I did this:

Python 2.7.17 (default, Oct 22 2019, 18:27:39) 
[GCC 9.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socks
>>> socks.__file__
'/usr/lib/python2.7/site-packages/socks.pyc'
>>> import ypkg2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named ypkg2
>>>

I don't know what's going on with this specific module

update: I've done some digging and connected some dots and I think I figured out what's going on.

So right now, eopkg sr, hs, or info won't run without sudo (abnormal). Peek didn't work because of gsettings schema issues (can't find its own). And lighdm refuses to put me in a graphical interface.
What those seemingly unrelated issues have in common is the privileges of which they were installed/updated from the package manager -- eopkg.

Recently I've changed my user umask (in $HOME/.profile) to 027 because my machine is shared among multiple users. I also changed the perms in my homedir to reflect that. I'm the only user on that machine with sudo privileges. And it seems like every single package, eopkg database entry, etc etc, that was added after the umask was in effect, actually respected my own user's umask instead of root's. The result was benign un-immediate broken installations and configs.
ls -ling /var/lib/eopkg/history reflects that. Every operation entry after a certain point in time has 0-other perms.

I don't think eopkg was designed with the intention of using user environment in mind. I think it should honour correct perms regardless of context instead.. Right? Is this a bug in how eopkg handles perms?

update2: Did some RTFMing and turns out this is mainly sudo's fault.

sudo's config has an option: umask_override for this exact issue. What I imagine might be a good idea is to make sure that option is set by default in /etc/sudoers that comes bundled with the sudo package.. or to have eopkg override that anyway with the correct file perms as they were packaged-in.

@hyphens, does this issue still happen with an up to date Solus installation? There have been many updates and bug fixes since this issue was last updated.

I cannot reproduce:

ermo@solbox:~
$ python
Python 2.7.18 (default, Nov 22 2022, 08:53:19) 
[GCC 12.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ypkg2
>>>
ermo@solbox:~
$ ypkg
[Error] Please provide a filename

usage: ypkg [-h] [-n] [-v] [-f] [-D OUTPUT_DIR] [filename]

Ypkg

positional arguments:
  filename              Path to the ypkg YAML file

optional arguments:
  -h, --help            show this help message and exit
  -n, --no-colors       Disable color output
  -v, --version         Show version information and exit
  -f, --force           Force install dependencies, i.e. no prompt
  -D OUTPUT_DIR, --output-dir OUTPUT_DIR
                        Set the output directory for resulting files
ermo@solbox:~
$

Note that we've changed the default umask to be slightly more strict since this issue was posted, yet the change has not affected ypkg and eopkg negatively as far as I can tell.