New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] version 4.0 #1584

Open
ultrabug opened this Issue Nov 25, 2018 · 9 comments

Comments

Projects
None yet
6 participants
@ultrabug
Copy link
Owner

ultrabug commented Nov 25, 2018

This is me writing down my wishes (and dreams) for version 4.0 and I hope I won't hurt anyone in doing so because I'm a rather drastic person...

As always, I'd love your ideas too. I'll edit this post if something else comes into my mind.

python

  • get rid of python 2.7
  • fully asyncio based
  • minimal version of python = 3.6

drop the formatter

  • use python f-strings formatting only

seamless configuration updates

  • configuration reader should backup and update user config on the fly
  • allows faster / easier deprecation of config etc
  • reports on a special file to user inspection (and auto backups as mentioned earlier)
  • would be auto by default, with ask-me-first or never options

make i3status a module like any other

  • would be launched seamlessly if config use a i3status module
  • but would be removed from core

usage tracking (opt-out by default)

  • allow users to share their usage and love of py3status
  • provided as a module with no output

make thresholds & borders general options

  • in the core

implement a dbus event handler for modules

  • already worked on #1547 so it should be rather easy

add default short_text support

  • can be overridden per module
  • reference PR : #1494

@ultrabug ultrabug added this to the 4.0 milestone Nov 25, 2018

@ultrabug ultrabug self-assigned this Nov 25, 2018

@maximbaz

This comment has been minimized.

Copy link
Collaborator

maximbaz commented Nov 25, 2018

drop the formatter & use python f-strings formatting only

Looking at my config, I use nothing else except conditionals (which are supported by f-strings), setting specific color (e.g. color=degraded) and setting color based on threshold (e.g. color=free_disk_space with thresholds={'free_disk_space': [(0, 'bad'), (10, 'degraded'), (20, 'good')]} ) - if it's possible to support these use-cases with f-strings, I would be happy.

@lasers

This comment has been minimized.

Copy link
Collaborator

lasers commented Nov 25, 2018

ability to import Xresources colors

  • Apply bad, degraded, good to default "red, yellow, green" numbers... so users can synchronize colors everywhere. I'm guessing we would use color0, color1, color2, etc.

    i3wm allows this in their config using set_from_resource $black color0 #000000.

sensible config paths

  • ~/.config/py3status/config -- default
  • ~/.config/py3status/modules -- default

Nothing to do with i3status or i3 config paths. Users should move them over. Right now, we have 6 or 7 different places to check. It is good time to make our own config directory.

simplify configs

  • We can just hide all on_udev configs in post_config_hook and fix on_udev to be like thresholds so it can pull a config and check (oh it's empty) immediately instead of dir(self.module_class). It's more optimized this way. There are other configs that users don't care about like request_timeout.

@ultrabug

This comment has been minimized.

Copy link
Owner Author

ultrabug commented Nov 25, 2018

Looking at my config, I use nothing else except conditionals (which are supported by f-strings), setting specific color (e.g. color=degraded) and setting color based on threshold (e.g. color=free_disk_space with thresholds={'free_disk_space': [(0, 'bad'), (10, 'degraded'), (20, 'good')]} ) - if it's possible to support these use-cases with f-strings, I would be happy.

thresholds going core will have to cover this topic I suppose

@L0ric0

This comment has been minimized.

Copy link
Contributor

L0ric0 commented Jan 6, 2019

minimal version of python = 3.6

is there a reason to use 3.6 as minimal version? If not I would be in favor to set the minimal python version to the python3 version in debian stable (3.5.3).

@lasers

This comment has been minimized.

Copy link
Collaborator

lasers commented Jan 6, 2019

I believe it was because of f-Strings in Python 3.6.

See if we can use native Python's {name.lower()} and some others instead of keep expanding our (rather basic) block formatter (i.e. [\?lower {name}]). I'm guessing we would treat placeholders as variables... or go one level deeper to deal with a whole format string.

It's likely faster, more clean, and probably fewer errors, etc... and we might be able to do more with that such as adding, subtracting, multiplying, cutting off things.

Also because Python 2.7 will be retiring in 2020 https://pythonclock.org/. Py3status have several codes to deal with Python2 and other unrelated codes. Better to make a leap right away to 3.6 and clean up things we don't need.

It looks like the full freeze date for Debian Buster is right around March 12, so Debian Buster might be released sometimes around middle of 2019.

Honestly, I don't know. This might be confusing as hell for the users... just the same.

@m45t3r

This comment has been minimized.

Copy link
Contributor

m45t3r commented Jan 15, 2019

Some other nice improvements that you can get going to Python 3 only:

  • Substitute usage of which in Py3.check_commands() for shutil.which() function: https://docs.python.org/3/library/shutil.html#shutil.which. This will avoid calling a binary.
  • Use subprocess.run() in place of subprocess.Popen() (mostly because the interface is cleaner, not much real benefits)
@m45t3r

This comment has been minimized.

Copy link
Contributor

m45t3r commented Jan 18, 2019

Just an idea to get some progress in this issue: merge all remaining PRs, starting to remove all compatibility code for Python 2 and make the code Python 3 only (after the release o 3.16, of course). The rest of the improvements can come later.

@AnwariasEu

This comment has been minimized.

Copy link
Contributor

AnwariasEu commented Jan 24, 2019

There are plenty of great ideas moving forward to version 4.0!

My personal favorites are:

  • python f-strings for formatting:
    • Making use of existing formatting definitions allows users, as well as developers to write more and more simple formatters
    • There is no need for a separated documentation on who to format string
  • DBus interfacing:
    • Less system load
    • Faster event handling, since it no longer depends on the refresh interval
    • IMHO: cleaner way of interacting with the OS and other processes, as long as the DBus interface is implemented correctly

To clarify the state of the proposed usage-behavior:

  • It is deactivated by default and can be opted-in?
    • What information is gathered?
    • Where is it stored? Is it processed or forwarded in any way, if so will this information be public?
    • Is there a way to verify no information you don't want to leak is send, e.g. by printing what kind of information would be collected?

Ditching older python versions:

  • Hard requirement for python f-strings
    • Will break newer builds for current Debian stable, soon to be Debian old-stable
    • Is this something to worry about?
    • Tag last versions before loosing support for older versions for simple builds of older versions?
@ultrabug

This comment has been minimized.

Copy link
Owner Author

ultrabug commented Feb 3, 2019

To clarify the state of the proposed usage-behavior

Just to be sure that everyone is on the same page: nothing has been done on this subject and even more: we will never to collect anything behind the back of users.

  • So yes, this would be totally opt-in (a module you add yourself to your config)
  • Information collected? dunno yet, we will discuss this openly but it will be data that will help us focus on real usage
  • Storage? dunno, I'm not even sure we'd like to store something
  • Verify information: we could make it clickable but anyway, module source code will be open source just as everything in this project :)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment