thoughts on 3.14

[tobes]

So we have a new release due so I think now might be a good time to think about a more focused dev window for 3.14

I'd like to see

1. less churn for the sake of it and more justifiable reasons for changes

2. some thinking around formatting and why how we use it. I'd like to see a fully replaced formatter in 3.15 and part of that is seeing what syntax we need. I think we can improve how we do this to simplify the whole process for users

3. config rewritting - I have a branch for this but it is a little out of date so needs fixes for new functionality. This will make it then possible to do parameter cleanups etc in modules

4. Look at creating some core functionality for modules to use eg dbus support, on/offline triggers etc. Currently we have modules doing much of this themselves and a central method would be nice. I'm not saying we should merge this but more work towards getting ready for it.

5. short_text/pango support

6. I'm also keen to try to get the events running in threads stuff fixed up/rewritten

7. review and simplification of some of the core code eg modules

8. logo :)

For things like the formatter I think it would be good to try to get a core vision about where we are going because currently it feels we are pulling in different directions and I see the same patterns repeating. Maybe we should look at having a py3status.con

[cyrinux]

We can add also, a logo to the list :)
I'm coming with a proposal logo my gf made for us.

[maximbaz]

on/offline triggers etc.

Specifically I would like to (1) disable module refresh while I'm offline (maybe a new cache_timeout_offline that I can set to -1), and (2) ability to refresh the modules right after I get back online, i.e. not waiting for the next tick of cache_timeout.

[tobes]

Specifically I would like to (1) disable module refresh while I'm offline

I'm thinking that a module registers itself we could either use the existing py3.register_function()

and have 'offline'/'online' or something similar - (maybe even both) but if we can have it super simple that's great

usecases I see are

• only update when online eg github
• update when online/offline changes eg online_status

So maybe online_status_change function that is called when we go on/off line would work but maybe we should have a more state_change function and register states we care about so we have future flexibility.

I'm against any user settings because I just don't think we need them

I'm open to other suggestions on how best to do this though

[maximbaz]

only update when online eg github

Precisely, I can't work on github while I'm offline so no need to refresh the module, and as soon as I get internet access, I am potentially ready to open github, so github module should be updated as soon I get back online.

[ultrabug]

Milestone proposal for https://github.com/ultrabug/py3status/milestone/10

Release focus & policy:

1. core only, no work on modules, no new modules
2. short_text/pango support
3. review and simplification of some of the core code eg modules
4. look at creating some core functionality for modules to use eg dbus support, on/offline triggers etc.
5. a logo!?

[tobes]

no work on modules

excluding bug fixes

no new modules

but we can get them ready for 3.15

[maximbaz]

Finding a solution for #1439 that everyone will be happy. This is probably included in the "work on core", but I wanted to mention it explicitly 🙂 All I want is to make left click not refresh the module, but instead show a notification with full output of the script.

[lasers]

Yes work on modules... to clear out issues and pull requests. I finished systemd stuffs which would at least clear us two sitting PRs (albeit a module from scratch). I also don't want to leave do_not_disturb PR sitting there until 3.15.

I have some more simple issues/PRs sitting too... which I'd like to have them addressed early on to get most of them out of way before we worry about new things.

We also have two 2016 open issues.

[ultrabug]

@lasers so what are you suggesting? another modules oriented release? we have to choose imho.

[lasers]

I'm suggesting a cleanup oriented release... We address enough issues and pull requests to get them on 1 page each. Somebody can take a lead on this or go with a different oriented release as I am going to be out of commission for a little while. My thoughts on cleanup oriented release... Enhancements to review/merge. * Allow module to use the general "markup" config (ready) * module_test: print modules in terminal (ready) * gitlab: use py3.get_color_names_list helper (ready) * py3: add threshold string support (ready) * clean and improve screenshots generation (?) * (any other finished enhancements?) Enhancements to close: * WIP improve get_color_names_list() # close or token color values (?) Modules to review/merge. * Merge velib_metropole and speedtest. I think they're good enough to be merged. Check with author first to see if he want to change something since I last changed things. IIRC he signed off on speedtest. Idk about velib. * From scratch... do_not_disturb and newmodule-systemd. They're finished AFAIK so this would close/change some. Wild changes tho. * Mega could have colors (threshold strings) in format_sync. I'm thinking colorized sync states on size placeholders or sync states... to print good/degraded/bad 4.38 GB or Synced. Otherwise, we have plain Synced. This can be for multiple dirs so "Mega Synced Synced Synced" is a bad default config if that happens... hence the future colorized thersholds strings. If threshold string support is merged, this probably could be fixed pretty fast. * keyboard_layout: add variant (the new placeholder is not published as it's the minimal diff enough to close an issue, but the code might fare better if it was rewritten from scratch). (ready) Enhancements awaiting/requiring some changes first: * module: add background and border colors (requiring Py3 class / functions) * module: add more module/global options (fix/rebase later).

[ultrabug]

I think 3.14 is due now, we have done a good enough jobs and some critical and exciting stuff are in and users could benefit from it.

Is there any blocker issue/PR for you guys in the spirit of this release?

Thanks

[lasers]

I wanted to address 3 things since we're in 3.14 enhancement milestone.

#1555 - Fixing py3status --help is easy. I assume we are waiting on your feedback because we stopped there due to updated flake8. I wanted to at least rename -m, --disable-click_events to -m, --mouseless so everything would line up nicely... or do we stick with with current py3status --help?

We don't support ~/.config/py3status/config, --include ~/.config/py3status/modules/ out of box. I think that could be fixed too.

#1486 - Get color backgrounds and borders in... for core 3.14? Omfg. Need to fix Py3(self)._get_color(parameter) to be instantiated once. @tobes (?)

#1481 - This can come next after 1486.

---

Different topic: Authors shouldn't be part of commit messages or we get duplicate authors when manipulating git log to format messages, author, dates, etc.

refactor and document extra requirements, by Ultrabug
add missing documentation on gevent option, by Ultrabug
fix black formatting, by Ultrabug
allow test_modules to use udev_monitor (#1558), by @lasers, by lasers
module: rename min_width,align to min_length,position (#1551), by @lasers, by lasers
py3: notify_user module name in the title (#1556), by @lasers, by lasers
fix flake8 W605 errors in core and disable test for modules (#1560), by @tobes, by tobes
parse_config: raise error on invalid modules (fixes #1523), by @lasers, by lasers
fix refresh of module on udev event, by Ultrabug
implement udev event monitoring (#1546), by Ultrabug
add .config/i3/py3status in default user modules include directories, by Ultrabug
adds ~/.config/i3 as a default config directory, closes #1548, by Ultrabug
py3: add threshold string support (#1480), by @lasers, by lasers
fix black CI, by Ultrabug
add markup (pango) support for modules (#1408), by @MikaYuoadas, by Akim Sadaoui
clean and improve screenshots generation (#1535), by @tobes, by tobes
Merge pull request #1539 from ultrabug/module_test_term, by Ultrabug
module_test: print modules in terminal, by lasers
Merge pull request #1507 from ultrabug/trove-classifier, by Ultrabug
setup.py, travis.yml: add python 3.7 support, by lasers
fix CI and add black tests, by Ultrabug
black: setup, by Ultrabug
black: tests, by Ultrabug
black: py3status core, by Ultrabug

[lasers]

@tobes I catched up to master on #1555, #1486.

#1555 is what you want (I meant that as I did what you want). I'm fine (and Idc) about long names. It's just different (compacted). Things that are not used by default won't have (default: message) in the description. Sorta because I hadn't looked at -i default path since I assume default path is not coming from argparse. Also, we should document the hidden commands eventually too. This ought to be good to go.

#1486 is waiting for instantiated once deal (waiting for you to look into this). After getting this implemented, I can refresh #1481 next... then we could put out 3.14 if you agree with this plan.

[tobes]

#1555 is what you want

Some but not enough :(

#1486

I would want to see some actual justification for this PR - but mainly I am tired - there are too many open PRs and you keep switching your focus. So for now you will have to wait for my input, then I will only work on a single one of your PRs till either it is merge-able or you close it. Sorry but you broke me.

[lasers]

I would want to see some actual justification for this PR

You saw the screenshots. I'm not sure how we can justify not supporting this. Already possible too.

but mainly I am tired
there are too many open PRs

3.15 is where I hopefully can fix some idle issues/pull requests in py3status without you.

Sorry but you broke me.

3.16 is where I hopefully can fix you by the time I'm finished with 3.15.

[ultrabug]

I will release 3.14 after #1567 FYI

[maximbaz]

#1567 is closed, but the π release wasn't published 😉

What will be the focus for 3.15?

[lasers]

@ultrabug, @tobes: Do you have a plan in mind for 3.15? I personally want to close many issues and pull requests as I can. I also want to consolidate some modules. There will be some breakage there and there due to minor changes, removed configs, etc. All of this is required to simplify do_not_disturb, systemd, and many more.

• Rename scratchpad_{async,counter} to scratchpad. I finished this.
• Rename window_title{async,} to window_title. I hadn't finished this.
• Rename apt_updates, arch_updates to updates. I made this to replace update modules. I tested this with Solus, Ubuntu, and Arch. All printed out okay. I don't have Fedora. fedora_updates could be removed too if I had a tester.
• I won't merge things I'm uneasy with, but I do want to swap out modules. I'm speaking of pomodoro and taskwarrior and such. Lot of modules from scratch are sitting there.
• I would suggest to merge stopwatch now... and worry about consolidating this into timer later. I will leave my new modules to you because I don't use them all. Module pew is very simple and can be useful for some users, but like I said, very simple. It does its job and that's it. Do we want to merge it or not? I need to know which modules you do not want to merge, or want to close. I'm okay with closing them all as it's the fastest way to clean up issues/pull requests. Cheers.

[maximbaz]

If you are planning to remove modules, I suggest bumping major version, doing breaking changes in minor version bump is no-no. Maybe for 3.15 mark those modules as deprecated and merge the new "consolidated" module, and in 4.0 remove deprecated modules. Also, in 4.0 you can cleanup all configs that are currently marked as deprecated, to cleanup codebase — searching for "deprecated" reveals soooo many matches now.

[maximbaz]

Do we want to merge it or not? I need to know which modules you do not want to merge, or want to close. I'm okay with closing them all as it's the fastest way to clean up issues/pull requests. Cheers.

Although I wasn't technically asked and we didn't agree on #1566, I propose to try applying the new rule in this case: for every PR determine if the author himself (or some other known to us person) is going to use this module, if the answer is no — close the PR (and potentially move it to py3status-contrib repo). If the answer is yes, we continue discussions in the corresponding PRs. Consilidated modules such as updates count as ones having users, because apt_updates and such did have users, so we don't close them immediately but discuss on case-by-case basis.

[lasers]

I have branch to consolidate scratchpad modules... and to notify users if they have scratchpad_{async,counter} in order += or in module_name {} with message...

OBSOLETE MODULE: Rename `scratchpad_async example` to `scratchpad example`.

... so they can rename it themselves. Otherwise, we will have all three scratchpad modules for next year or two. Same for window_title and update modules. I feel this approach is simple and clean... and maybe better than us trying to silently edit their configs.

I recall @tobes say something about needing to brush up on his config rewriting branch. I'm not sure what the plan is for 3.15. Even if we change their configs and make everything work fine, we ought to still notify users know about deprecated modules.

Notifying users is a simple clean code (imho). Users might like it more if we tell them to fix their configs instead of us doing it ourselves quietly... And even if we do it ourselves quietly and still notify users, then it could be a waste of code because they're going to do it themselves to kill annoying notifications.

@ultrabug, @tobes Please chime in. It's the weekend. :-)

[tobes]

Yeah I want to get the config re-writer done but it needs some work to do it nicely (and it is not my first priority). I'd say until we have this I think we should not be changing things very much.

I'm opposed to module rewrites unless we have a real reason. They cause lots of work and slow don the project. Realistically we need to get to a manageable number of issues/PRs. Currently we have too many. If I was working on this full time I would have serious concerns about the number of open issues/PRs it is not sustainable. Just to go through and try and prioritize them properly is a days work.

For 3.15 The plan is to make the black changes to modules. This could be a pain with module PRs but @ultrabug is keen on this. Consistency is important so I have no problem. I may see if I can persuade him to reduce the max line length to 79 as this is something that I care deeply about, but he is more liberal on this than I am.

Basically I'd go with the if it ain't broke don't fix it approach, so renaming is in that category. I'd like us to fix the broken modules, rather than rearranging deckchairs.

For me I'll see how my energy levels are and how much time I have, the end of the year is often a good time for code as the nights get darker.

[maximbaz]

I support @lasers in the general sense of wanting to cleanup stuff, that is to clean codebase from deprecated properties and reduce number of modules (i.e. merge almost duplicate modules). Less code to maintain is a good investment strategy.

At the same time I totally understand your desire @tobes to finally get this repo under control, resolve long-standing tickets and reach zero PRs state.

I'd like to propose the following:

1. We go through open items and move "for-fun" PRs to a contrib repo.
2. We create a ticket called Prepare 4.0 release, link all cleanup PRs (those about deprecation and consolidation) to it, and close those PRs for now — this will leave open only things which are actually needed for 3.X release.
   • for example, I would mark new module: updates #1552 for 4.0 and close it, and would close arch_updates: alternatively use yay for AUR check #1545 because in 4.0 we will address this request (and arch_updates module will likely become obsolete anyway).
3. We burn down the remainder of PRs and issues getting to 0-PRs state and releasing one or several 3.X releases.
4. Then we return to 4.0 release, reopen and actively work on cleanup.

I can help you triage things and execute on the plan above.

How does this sound to you?

[tobes]

1. cleaning up the issues PRs is needed. Exactly how is an open question

2. I might go for a different name

#1545 I'd be for merging.

• It is a reasonable request and meets the contributors need

• I'm keen to accept PRs from new contributors

• It doesn't feel like it is over complicating the module (it does a small amount)

3. 0 PR is unlikely to happen but I'd like to get down to single figures

[maximbaz]

#1545 I'd be for merging.

Fine by me, it seems both you and me are far from being happy with consolidated updates module just yet, so if we can unblock that person in one of the upcoming 3.x releases, it's a nice and welcoming thing to do.

as to 1. and 2., think about it, if that's the approach you wanna take to cleaning up open itms, tell me and I can prepare the ticket (you can rename/edit it afterwards), or create it yourself 😉

[ultrabug]

Hey guys. First of all I want to apologize for my lack of responsiveness here. I feel bad about it.

So we have two different kinds of discussions here:

• this very issue, which transitioned from 3.14 focus to 3.15 focus on what should be included or not
• [discussion] new community rule: changes *must* have a real user #1566 which is about how we could organize ourselves better to get releases smoother

There's also comments on the 4.0 perspective...

I first would like to thank you all for the passion and energy you put into these discussions. I'm really moved by the very fact that you guys feel this project is important and fun to you.

This is also because we're all involved in this project that we feel a frustration about it not going fast enough. I would just like us to take a step back and acknowledge that less than 40 open PRs and issues is not that dramatic for an Open Source project :)

But we indeed face something that's a nice and sane problem actually: our popularity grew over time and we have trouble to maintain a balance between our wishes and our users' wishes (users who do not show up here for a vast majority of them).

So we're getting a bit schizophrenic and lost on our speculations on what they want/use!

I would like to quote one of the first things I wrote when I imagined and released py3status

Philosophy

    no added configuration file, use the standard i3status.conf
    rely on i3status' strengths and its existing configuration as much as possible
    be extensible, it must be easy for users to add their own stuff/output by writing a simple python class which will be loaded and executed dynamically
    easily allow interactivity with the i3bar
    add some built-in enhancement/transformation of basic i3status modules output

I'd like to say that in my humble opinion a project is good and smooth when the people behind it develop it with their real life experience as first class citizen. It's because we feel it has value to us that it has value to others! (like it or not, we're not special ahah)

In short, what makes some people like py3status is what derives from this philosophy: it's dead simple yet powerful to use.

With this in mind I will now:

• close this issue that was meant for 3.14
• comment on [discussion] new community rule: changes *must* have a real user #1566 and propose something we'll agree on
• create both 3.15 and 4.0 milestones
• open an issue to discuss what will be on 3.15
• open an issue to discuss what will be on 4.0

I will thus continue in more details on #1566. Thank you!