Comment by zahlman | Hacker News Reader

Comment by zahlman | Hacker News Reader

Parent Full thread

> Additionally, I disagreed with the default way of installing Qtile. As a principle, I never sudo pip install anything. Instead, I asked my friend Karthikeyan Singaravel, who is a Python core developer, and he recommended using the deadsnakes PPA for Ubuntu to install any version of Python that I chose. I tried compiling python 3.10 myself, installing to /opt/qtile/ using configure --prefix /opt/qtile/ during the configuration stage of the source code. However, I admit that using deadsnakes is a far better idea since I could create a virtual environment based on python3.10 into /opt/qtile/ instead. I had to change the owner of the folder to my user account. Note that I could store the virtual environment in my home folder and just use that, but I wanted to isolate this outside of my home folder.

Qtile doesn't appear to be tied to a specific Python version. Could you not have made a virtual environment based off the system Python? For that matter, could you not have made a virtual environment from a local compiled-from-source Python? (I do that all the time, because I'm interested in testing against specific Python versions and comparing their performance characteristics.)

> Then, I changed the owner of the folder to my regular user account.

> Then, it was time to install qtile.

> I created /usr/share/xsessions/qtile.desktop and filled it with the following:

Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)

> After this, I logged out of my previous window manager and switched to the new entry for Qtile.

Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?

> Qtile’s config file rests at ~/.config/qtile/config.py

So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?

> Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)

I changed the permissions so everyone can run the binary.

You _can_ use a venv. I prefer a dedicated environment for this. I've been using Mise-en-place lately, it's great.

> Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?

Yep. Your login manager will pick it up.

> So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?

Yeah, you can. It's self-contained. I even setup ansible-based dotfile installation in https://GitHub.com/stonecharioteer/distributed-dotfiles.

While qtile doesn't care about the python version, I do. I've grown wary of environment clobbering, it's an issue that Python has had, one that even Ruby does better than it, I've discovered. I like isolating these, helps debug a lot. Now I have added more shortcuts to my config using Rofi scripts, I can see the Qtile log, access, the dunst notification history and other stuff easily with rofi. Give Qtile a go if you've been looking for a Tiling Window Manager. It's married to the Qtile Bar, though, but the Bar can do almost everything.

> You _can_ use a venv. I prefer a dedicated environment for this.

A venv is Python’s built-in way to handle dedicated environments. It’s what mise and uv use.

> I've grown wary of environment clobbering, it's an issue that Python has had, one that even Ruby does better than it, I've discovered. I like isolating these, helps debug a lot.

That’s a Python virtualenv. It’s had these for many years. I don’t know if there’s even any other way to get the same isolation with Python, short of using a container or something else at the OS level.

> I don’t know if there’s even any other way to get the same isolation with Python, short of using a container or something else at the OS level.

You can, but you have to hack it together yourself, e.g. by modifying sys.path or setting up hooks that will do so (e.g. by creating a `usercustomize.py` or `sitecustomize.py` that gets pulled in by the standard library `site` module). And then it will amount to almost the same thing anyway, because there's really no reason for anything else.

The virtual environment itself is really barely anything at all: a place to put installed packages, and a `pyvenv.cfg` config/marker file that Python uses to automate said sys.path hacking at startup. Oh, and a bin/ subdirectory with symlinks (stub wrapper executables on Windows) to Python, and also a place to put entry-point wrapper scripts for the installed code. That's the main thing that isn't necessary for isolation, but it's pretty convenient. Oh, and some "activation" scripts that hack some environment variables together to make the environment easier to use (see, it's the use of those symlinks that determines whether the venv's packages are used).

The built-in support (such that `pyvenv.cfg` files are created and the Python binary directly cares about them) has existed since 2012, and its third-party basis (which automated the sys.path hacking in a somewhat more brutal way; https://archive.org/details/pyvideo_568___reverse-engineerin... is quite informative) since 2007.

My reply here is to people reading along. I know you know this stuff.

Yeah, I can imagine hacking something together on my own if I had to ("first run `zfs create tank/myproject`...") but I'm glad I don't. I'm not referring to the person here, but I've seen people go to great lengths to avoid virtualenvs when they're about as lightweight as such a thing can possibly be. Like, this is the entire process for using one in a project:

  $ python -m venv .venv
  $ source .venv/bin/activate

Now if you run `pip install foo` in that shell, it'll install the package inside that virtualenv. If your code has `import foo` somewhere, it'll load the virtualenv's package, no matter what versions of foo are installed elsewhere. It's nearly identical in concept to Node's ./node_modules directories, except that you have to explicitly activate the virtualenv, which also gives you the flexibility to easily use the same venv for multiple projects if you really want to.

If you have something like mise or uv, you can ask them to manage a venv for you, but they're conceptually just wrappers around those steps.

I compile python from source when I'm being particularly anal about isolation. Used to have playbooks for that too.

That’s totally a thing you can do, but I don’t think it gets you anything at all over just using the built-in virtualenvs. (Although lots of people create them with uv or mise or poetry or whatever, the feature is part of Python itself, and all those tools do is create and configure them for you.)

Also, pyenv and uv are wonderful ways to install whatever version you want without having to compile them locally, and you can have many versions installed at once and use a different one for each virtualenv if you want to.

I use mise with uv, and it works great. https://mise.jdx.dev/mise-cookbook/python.html

This is the way. Or even just plain uv, although I also use it from within mise.

[disclaimer, maintainer here]

> Doesn't this require the environment to be owned by root? Doesn't it make more sense to leave things that are in /opt as root-owned anyway? (Or at least, change them back after running the installation as an unprivileged user.)

No, it doesn't require that, it just means your user-owned binary will be exec'd by root. But if you want the root -> user owned indirection, you can set `Exec=/etc/X11/xinit/Xsession`, which will exec your ~/.xsession as your user, and then you can keep a local install.

> Will any random greeter program just naturally pick up the contents of /usr/share/xsessions, then?

Ones that support x11 do, yes.

> So does it just ignore all your other dotfiles? Can I safely just try this out regardless of my usual WM/DE choices?

We try to read XDG_* things where relevant, e.g. themes and icons. But generally yes, once you point your xsession at qtile, we only use our config file.

Reply on news.ycombinator.com