Added Pyproject.toml, poetry lockfile, and some type annotations

[skewballfox]

I can add instructions for setting up the project with poetry to the readme if you like.

I can also roll back the changes to wayland-session if you are not a fan of type hinting in python

[Vladimir-csp]

Not sure I want to introduce more complexity into the project, but stricter control over types sounds nice. All the packages listed in poetry.lock, are they just some standard set, or something that would be nice to have to work with scope of tasks at hand, like color output and whiptail? I would like the script to work with minimal dependencies that are readily available in the distribution's repos and likely already installed. Currently it only requires, in Debian terms, python3-xdg, whiptail, kbd (and obviously, systemd, dbus-bin). Also I see some typos fixed, thanks. Should we target 3.11? Currently to my knowledge there is nothing in the script that requires 3.11, so it potentially can run on 3.7 for example.

[skewballfox]

All the packages listed in poetry.lock, are they just some standard set, or something that would be nice to have to work with scope of tasks at hand, like color output and whiptail?

the poetry.lock file is generated by poetry in the process of installing the dependencies listed in pyproject.toml (if the version constraints can be satisfied, sometimes they can't). The packages in the poetry.lock not specified are likely the dependency of one of the dependencies.

note that also packages are clustered in groups, so not all the packages listed in the lockfile will be installed by default, as some of them are probably a dependency of black which is only installed if someone runs poetry install --dev.

Should we target 3.11? Currently to my knowledge there is nothing in the script that requires 3.11, so it potentially can run on 3.7 for example

that was just the version I have as my default. I can specify a range, or multiple ranges(I think).

[Vladimir-csp]

let's go with >=3.7

[skewballfox]

is there any documention of when exactly stdin/stdout/stderror might be None most of the type warnings put out by pylance are about potentially using one of the strip methods on None. I'm honestly struggling to think of a case when those would be none.

[Vladimir-csp]

Thanks! I'm considering using subproceess.run instead of a custom wrapper, will review stream types along the way.

[Vladimir-csp]

in resutlting object stdout, stderr can be None if they were not captured into subprocess.PIPE in function arguments stdin, stdout, stderr set to None means the same as sys.stdin, sys.stdout, sys.stderr.