Create wheel and publish on PyPi

[altendky]

I suspect that many users of this library will not be interested in Git and submodules etc. At least, those that want to distribute would find it a bit smoother if there were a wheel. There are always nuances but building a wheel is pretty much just venv/bin/python setup.py bdist_wheel.

I'll try to get a PR for this. We've already got Travis going and I think this is pure Python so we should be able to build a universal wheel there. Probably also use https://github.com/habnabit/vcversioner (I've used it for my own project).

[jbm950]

I think it would be wonderful if pip install pysunspec could pull straight from PyPi. The pull request would be greatly appreciated and we can get Bob to setup the wheel on PyPi.

I haven't had much experience with versioning of projects and so what is the issue with that arises with just specifying an issue within the setup.py rather than trying to make it dynamic?

[altendky]

First thing is that I learned that Travis doesn't store build artifacts, so they would have to be uploaded to elsewhere at the time of build. I am personally used to build systems storing artifacts from every single build and then separately handling any release process (such as to PyPi). It's nice to be able to bisect for issues without having to build every copy. I would much rather work in Linux but because of the above issue (and my simplistic needs for now) I went ahead and setup a build on AppVeyor for my fork. Since I had already done similar for a couple other builds the appveyor.yml wasn't too big a deal.

Versioning in the setup.py is icky because you have to decide the version before you commit... I much prefer being able to commit, get a build server result, use it, share it around, etc and only then decide that yes, that commit was good. Then, tag it in Git with the version number, build again, and you get a build of that commit with the release version. Admittedly, auto versioners aren't going to guarantee unique numbers across multiple branches (I don't think?) but at least you won't have 50 commits all reporting the same version number. Notice my AppVeyor version number v1.1.0.dev2.post61. I picked v1.1.0.dev2 because it was in the future and gave it a dev number, but that's all just because I wanted to get to something unique (and wasn't familiar with vcversioner at the time). The real point of this comment is the post61. That says the commit is 61 commits after v1.1.0.dev2. Automatically unique numbers without having to remember to change them every commit.

To be clear, the v1.1.0 formal release numbers are still manual. You pick a Git commit, you apply the version number as a tag, then you rebuild that commit (or it detects the tag and builds automatically). You retain full control over what gets those numbers and what the numbers are.

TL;DR
I think it would be just as well to have tests run on Windows (aka, AppVeyor) as well as Linux (Travis) and AppVeyor provides a simpler setup for maintaining build artifacts, so an AppVeyor build seems like a good choice. They provide some mechanism for PyPi uploads but I haven't used it and manual isn't that hard at least to start with. Do keep in mind that once a file is uploaded to PyPi it can only be deleted, not modified or replaced. So, don't do test uploads to the official public PyPi server.

[peteretep]

Hello, is there any plans to publish this package on pypi? We are using it in a project and it would make things a lot easier if we could pull from pypi.
Happy to help if we can, we have some experience packaging for pypi

[altendky]

Note that there is a new repository and a new ticket for it as well. sunspec/pysunspec2#13

Anyways, I give in. Here we are.

https://pypi.org/project/pysunspec/
https://pypi.org/project/pysunspec2/

I do still need to follow up on another release since I don't think pysunspec v1.0.8 actually worked with py3 so I need to find at least that rev. Plus I'll have to toss in my own additional rev with #61 since that never got merged.

[peteretep]

great, thank you. Will need to review our devices and make sure we are using the correct package.

[altendky]

Alrighty, so I also need to revisit what models are included in each release since they weren't made a separate package. They also weren't always a sub-module so I'll have to go pick some model version to use for those releases.

[altendky]

I think I got the models with the vX.Y.Z.1 releases. Also put out an updated copy of my fork as v2.1.0.

For anyone thinking this is all around a not-great thing to do... I agree. But, 1) it has been years and 2) I can share or transfer access and 3) the distribution name should really be sunspec (and sunspec2) to match the import name. So really, the _proper_ names are still unclaimed.

[altendky]

@shelcrow, I was going to add you as a maintainer on these projects so you could upload new releases. I decided I ought to do at least some minimal identity check beyond the email from address. :] I'll trust GitHub accounts and organization associations for that. Could you just confirm your PyPI username here? Thanks.

[shelcrow]

@altendky sheldon_sunspec

Thanks

[altendky]

SunSpec has decided that they do not want me to have any access to the PyPI projects. I have very little interest in dealing with their focus on control over progress. I will be giving them ownership and expect to be immediately and permanently removed from both projects. We'll see if they bother to make the libraries easier to use with releases on PyPI.

[bobfox]

SunSpec is simply trying to correct the issue raised multiple times of github releases making it to PyPI in a standard way. This has nothing to do with any specific person and is just SunSpec trying own its product and take responsibility to correct a longstanding problem.

[altendky]

I gave Sheldon rights to upload and expressed that my hope was to hand over control to SunSpec after proof that users wouldn't be left without PyPI releases for an extended period. The follow up emails continued to push that SunSpec must have complete control.