publish to pypi
HBehrens opened this issue · comments
Simplify usage by publishing to pypi as suggested by @carlescufi at the zephyr project. May require some thought around versioning.
I'm curious why you think versioning requires more thought than slapping a version on it? I think the only outside requirement now is that Zephyr requires the command line invocation to work as it does today, but you would pretty easily coordinate an update to that repo to pin a version.
I'm also happy to take this task on or chat about it, I now have a decent workflow for doing this from publishing all the gdbundle plugins.
Oh wow, thank you @tyhoff help or sharing best practices/recommendations would be much appreciated! I've only ever published a package once and that's been a while.
I am not sure about the version, it was simply something to consider once you go "public", I guess. puncover/version.py currently says 0.0.1, that's probably "safe" to go with? Or would the workflow you had in mind generate a version number (e.g. .patch component) automatically?
setup.py in this repo seems to be almost ready once you use twine. At the very least, I wanted to do some testing on macOS and Linux though. And a really nice feature to have would be automatic publishing (e.g. whenever travis detects a version tag associated with the commit).
What did you have in mind? Which user would you publish this with? Would hbehrens be a good choice? If so and if you are willing to put in the work, do you want me to upload an API token as a secret (travis)?
A couple of quick comments based on my own experience with pypi.
I am not sure about the version, it was simply something to consider once you go "public", I guess.
puncover/version.pycurrently says0.0.1, that's probably "safe" to go with? Or would the workflow you had in mind generate a version number (e.g..patchcomponent) automatically?
I would recommend starting with a low number, something like 0.1.0, and go from there. There is no tricks or secrets to publish a package to pypi, it is trivial in itself.
setup.pyin this repo seems to be almost ready once you use twine. At the very least, I wanted to do some testing on macOS and Linux though. And a really nice feature to have would be automatic publishing (e.g. whenever travis detects a version tag associated with the commit).
We don't have automatic publishing for much bigger projects than this one, so to be honest I think you can defer that and just run twine manually every time you cut a release. What does help is having a suite of tests that are run every time you post a PR, so that when you post the one that increases the version number you are more or less confident that the code is not broken. You can take a quick look at how it's done in Zephyr's west using tox:
https://github.com/zephyrproject-rtos/west/tree/master/tests
EDIT: I see you are pretty well covered in this regard actually, so in my opinion you are good to go with publishing on pypi.
What did you have in mind? Which user would you publish this with? Would
hbehrensbe a good choice? If so and if you are willing to put in the work, do you want me to upload an API token as a secret (travis)?
There are two ways you can go about this. My recommendation would be to have either a company or project-wide account that you share credentials with through something like LastPass, this is what we do in Zephyr and also at Nordic. The other option is to have your own account, and then you can actually add other pypi accounts to your own and give them permissions to publish new versions.
puncover is now published to PyPI 🎉 https://pypi.org/project/puncover/