Roadmap

[staticdev]

@sigmavirus24 I think we now have enough changes for a 2.0.0 release. I would like to test it in my apps before doing further changes.

I also have an idea of improvements I would do:

• Substitute setup.cfg and setup.py with pyproject.toml (as in PEP 517/518)
• Update tox to nox
• Refactor tests to use only pytest (no unittest)
• Add release drafter to Github Actions - to automate releases documentation on Github
• Add release pipeline to Github Actions - to automate releases on Pypi

I am already using all this in my projects, you can see as example https://github.com/staticdev/git-portfolio

[sigmavirus24]

Substitute setup.cfg and setup.py with pyproject.toml (as in PEP 517/518)

I've yet to see anything but headaches from pyproject.toml. I don't see any convincing arguments for it.

Update tox to nox

Why switch to nox? tox has parallelism at this point and other features that we could take advantage of, I'm not sure if the feature-parity is there.

Add release drafter to Github Actions - to automate releases documentation on Github

GitHub releases are a pox. I've done them before and people have ridiculous expectations around them that make me want to never do them again.

Add release pipeline to Github Actions - to automate releases on Pypi

This sounds handy

Refactor tests to use only pytest (no unittest)

This is nice, but since we no longer support py2, I'd rather effort be spent using MonkeyType to get annotations into the project

[sigmavirus24]

Also there's plenty of API surface area to cover. I think it'd be far better for users if we covered that first and foremost. Focus on the users, then contributors, then on us. (Type annotations, API coverage, etc.)

[staticdev]

Substitute setup.cfg and setup.py with pyproject.toml (as in PEP 517/518)

I've yet to see anything but headaches from pyproject.toml. I don't see any convincing arguments for it.

I have to say, as an early enthusiast of pyproject.toml, I didn't have a good experience in the beginning. But now with dozens of projects using it, I can see the benefits of using it together with poetry (which is much more stable after version 1.0.0). The dependency management and deploys are greatly simplified.

I can bump the version and release one application in seconds. Also no more trouble with easy_install, setuptools, wheels.. I would say now just the opposite, that using it saves hours of work a month for me and also a lot do headaches less. Having the dependency tree versioned is not only beautiful and less ambiguous than generating lots of config files and requirements.txt.

Update tox to nox

Why switch to nox? tox has parallelism at this point and other features that we could take advantage of, I'm not sure if the feature-parity is there.

You are correct about that, nox does have parallelism that tox has. The main reason I prefer nox is that instead of having an INI file, you can extend and customize all the execution using python for more complex and complete verification. But for me no problem in sticking with tox.

Add release drafter to Github Actions - to automate releases documentation on Github

GitHub releases are a pox. I've done them before and people have ridiculous expectations around them that make me want to never do them again.

Yes, this is the main reason I like to automate it in all projects also. So you don't have to do any real work =)

I've also seen more then once, people comparing libraries by numbers of stars and releases (which is not at all a great measure but is used in practice).

Add release pipeline to Github Actions - to automate releases on Pypi

This sounds handy

=)

Refactor tests to use only pytest (no unittest)

This is nice, but since we no longer support py2, I'd rather effort be spent using MonkeyType to get annotations into the project

Sounds good to me too.

Also there's plenty of API surface area to cover. I think it'd be far better for users if we covered that first and foremost. Focus on the users, then contributors, then on us. (Type annotations, API coverage, etc.)

I totally agree, it is good to discuss roadmap to think where to invest given all features and improvements that can be done.

[staticdev]

Sorry for the long answer.
BTW, do you agree in releasing 2.0.0 on PyPI?

[sigmavirus24]

I have to say, as an early enthusiast of pyproject.toml, I didn't have a good experience in the beginning. But now with dozens of projects using it, I can see the benefits of using it together with poetry (which is much more stable after version 1.0.0). The dependency management and deploys are greatly simplified.

Has poetry finally added support for library development? If not, what's the value add for a project like github3.py?

Yes, this is the main reason I like to automate it in all projects also. So you don't have to do any real work =)

Until the automation silently breaks and then people start opening issues that a release isn't there. I genuinely don't want to encourage people to judge projects based on number of releases or anything of the sort. As you said, it's not a good measure, so why bother encouraging it?

[staticdev]

I have to say, as an early enthusiast of pyproject.toml, I didn't have a good experience in the beginning. But now with dozens of projects using it, I can see the benefits of using it together with poetry (which is much more stable after version 1.0.0). The dependency management and deploys are greatly simplified.

Has poetry finally added support for library development? If not, what's the value add for a project like github3.py?

I am not really sure what do you mean by support to libraries, but I have tons of exemples of libraries I maintain using it, just some very different examples I maintain to name a few:

• https://github.com/staticdev/git-portfolio
• https://github.com/staticdev/humanizer-portugues
• https://github.com/staticdev/django-sorting-bootstrap
• https://github.com/staticdev/toml-validator

Yes, this is the main reason I like to automate it in all projects also. So you don't have to do any real work =)

Until the automation silently breaks and then people start opening issues that a release isn't there. I genuinely don't want to encourage people to judge projects based on number of releases or anything of the sort. As you said, it's not a good measure, so why bother encouraging it?

Never happened to break with me on Github Actions since I started using like about one year ago.

[staticdev]

@sigmavirus24 friendly reminder on releasing 2.0.0 on PyPI. I don't have permissions to do that.

[sigmavirus24]

@staticdev 2.0 is out, thanks for the reminder

[NargiT]

Hello @sigmavirus24
It seems that releases are out but not tagged in github.

https://pypi.org/project/github3.py/#history
is this normal ?

[sigmavirus24]

@NargiT the releases are tagged. There is 0 real value in using GitHub releases for anything. Any releases that are there will be deleted when I'm at a computer because they obscure reality

[staticdev]

@sigmavirus24 to make people happy I created the last missing releases from the tags and release notes.

[NargiT]

@sigmavirus24 I don't agree, there is a real value with github release as I am subscribe to release notifications. Now you can decide to not do it, and I am fine with that. But as it was done before, I though you simply forgot to do it.

@staticdev thanks

[sigmavirus24]

@NargiT it's not a discussion. This kind of nagging is the exact reason why I find them actively detrimental