allenporter/python-google-nest-sdm

Please file releases!

onkelbeh opened this issue · 6 comments

onkelbeh commented

Hi,

could you please file releases here?
And, better, add SDIST archives at Pypi?

Thanks a lot!

\B.

allenporter commented

Very happy to do more here. Can you spell out in a bit more detail want you what you would like to see happen? I am new to releasing python libraries.

So far, twine was used to release versions here following some tutorial:
https://pypi.org/project/google-nest-sdm/

Are there additional options needrd when releasing? Or tag them on Github somehow?

onkelbeh commented

Hi, Allen,
Yes, sure.

your library supports an integration in Home Assistant, I would like to use your library in my Gentoo Overlay for Home Assistant, hope you don't mind.

  1. Therefore I would need a release file either at Pypi in SDIST format, or as a tar.gz on github. I cannot use a library in wheel format. Normally, when no SDIST can be found at Pypi, I would take the source from Github. This was not possible in this case, because you do not yet tag releases here.
  2. A release on Github is OK, but a Pypi SDIST tar.gz release would be preferred, because this could use Gentoo's mirror system and updates download stats. Most of the other (~1100) integrations I use for the repo have both. If something goes wrong with one release, I would have the chance to try the other. This happens from time to time. Would avoid holdups if other libraries depend on it.
  3. Please add a tag for 0.1.6. As soon as you add a tag, Github builds a usable source archive. Make sure that release points in Github are on the same commit which was used for the release in Pypi. See https://git-scm.com/book/en/v2/Git-Basics-Tagging
  4. If you build an SDIST for Pypi, make sure that all files needed for building are included. A common mistake is a missing requirements.txt or README.md, mostly opened by setup.py during compile process. There are many short tutorials out there how to script this on Github.
  5. One or more of the requirements of this library are pinned to a specific version. Hard pinning may work now, but will lead to problems if an other integration updates it's requirements. To avoid future issues it would be good if this library would change its pinning to allow any higher version and just set a minimum version. Especially when you pin very common libraries like aiohttp or requests-oauthlib.

Thanks a lot for your work.

\B.

  • 👍1
onkelbeh commented

Ah, and, sorry, forgot:

  1. It makes things easier if the library name at Pypi matches Github repository name.
allenporter commented

Thanks, very helpful guidance and context.

I found this tutorial for setting up requirements.txt from a venv: https://developer.akamai.com/blog/2017/06/21/how-building-virtual-python-environment

However it pins versions on everything. My impression is that requirements.txt is more for the dev environment: is pinning an OK practice in that case?

I'll check in the commands I'm using for release for extra visibility.

allenporter commented

Fixed with commits:
096adac,
870fd99,
444e324

onkelbeh commented

Yep. You made it! Thanks. Led to a couple of new Ebuilds:

  • add google-nest-sdm-0.1.6
  • update google-nest-sdm-0.1.9
  • add google-api-core-1.23.0
  • add google-auth-1.22.0
  • update google-auth-1.22.1
  • add grpc-google-iam-v1-0.12.3
  • add google-cloud-pubsub-2.1.0
  • add libcst-0.3.13
  • add proto-plus-1.11.0