Py3status: 3.0 release

[ultrabug]

So much as been done since 2.9 it's insane and impressive !

It's time to allow the other users to benefit from it so I'd like to call in a freeze of features and issue killing spree instead.

Let's list here the issues we want to be resolved for 3.0 and agree that the rest will come after ?

[tobes]

From my point of view.

1) I still have one outstanding PR that I would really like to get into version 3.0 but it relies on #248 so therefore is not queued currently. That PR would allow us to have much richer config files.
I know that you want to close the door on 3.0 but I feel that this PR would actually hugely benefit the 3.0 release and without it I feel it would be crippled. Basically it offers the following

• containers - like groups but anyone can create them (and #275 creates the need for a 'frame' container)
• parameters can be str, int, float, bool, None, list, dict, tuple
• really good errors eg 'CONFIG ERROR: Value expected saw } at line 102 position 7'
• bad config files do not kill py3status (it has an emergency mode - complete with error info)
• stable - I've been regularly using it for the last month.
• fixes #164

It is fairly self contained.

2) Documentation: I've made some headway but some of it is dependent on existing PRs eg color -everywhere. (this could wait but it would be nice to have)

3) Pomodoro - wants fixing

4) Weather-yahoo - fixing or killing

5) Oh I've also got a pull request that allows testing of new style modules that use self.py3

Anyhow I think we should try to bed things down for a couple of weeks, but I think calling it 3.0 yet would be premature. Especially in view of the composite patch where I'd like to do a secondary button patch on that.

[tobes]

One other important thing in my mind is around Py3 currently modules can use this to get 'legally' right inside of py3status. I'd like to close the door on that, which would be a very minor PR and I'd consider it a bug fix.

[pydsigner]

@tobes I don't think that's a real issue. Considering that a malicious module could just import os; os.system("rm -rf ~/"), weird py3status hackery seems like a minimal issue, and closing this down could potentially prevent some useful user-written modules.

[pydsigner]

@tobes Other than that, better config parsing is something that I would personally be willing to hold the 3.0 release for.

[tobes]

You see I believe this.

self.py3.get_module_info()['module'] gets me the module and then I can crawl around and should be supported. If I do self.py3._module it gives me the same but I know that what I do is not supported in any way.

That's all I mean just stopping user expectation.

Also self.py3.get_latest(module_name) is just nicer than self.py3.get_module_info(module_name)['module'].get_latest()

[tobes]

So I have been thinking.

For 3.0 I would like either.

• group module to be removed from the release.
• PR #275 Composites to be merged.

All my other PRs can sit in limbo (but always nice if merged)

My reasoning is this. The group module as it is in master is broken. We interfere with other modules click events. To solve that we need #275, which makes the group module really nice imho.

The config parser #282 adds lots but actually that is not needed at the moment, and will want significant review, so why risk potentially breaking things? The same with #279 color everywhere etc it adds stuff but we don't need that now.

The composites patch is pretty small (as far as core is concerned). I'd drop the timer module too as it is only there as a demo.

I would want to make some small changes to Py3 but I'd like to know which branches we will be pulling in first so as to make them easy to do otherwise they will cause merge conflicts. Add a get_output(module_name) and make get_module_info() private.

The second option is my preferred one. We add a nice new group module, and things would be set to do some great new/updated modules for 3.1

Anyhow that leaves:

fixing pomodoro - I said I'd do this and it should be fairly quick and painless.

#228 fixing weather_yahoo - registering for an api key is too much work for me as a user (needs a solution).

#204 XDG_CONFIG_HOME - would be good to fix.

169 click event crashes (probably needs a bit of changes) may be the try/catch would work for short term.

164 unicode config - long term python2 issue and will get fixed by config parser in future if accepted.

143 local mailboxes - there is PR #215 but that seems to have stalled.

Stuff in the PR queue (excluding anything from me).

[ultrabug]

I guess the recent events and merges are worth an update of the TODO here right ?

[ultrabug]

Okay, with the recent documentation updates we should be very close to a release, I'll start generating and summing up the insane CHANGELOG

[ultrabug]

It's live :yellow_heart: