[python-control-developers] A few questions about python-control

[Clancy R. <cwr...@pr...>]

Hi Richard,

A few things related to python-control:

1) PyPI.  There is a lingering issue (#19) about uploading to PyPI.  The last comment on there (from you, back in November) says that the next step is to upload v0.6.5 to pypi.  However, a version called 0.6.6 is already on PyPI.  Apparently James Goppert had uploaded this way back in September, in response to another issue (#37).  So my question is, what would you like to have happen on PyPI at this point?

My recommendation is to upload a new version called 0.6.7, with the current 'master' plus some changes I'm working on now (see #3 and #4 below).  I'm happy to do this myself if you agree.

2) Releases. More generally, it would be good to talk about how often to release a new version.  My own view is that we might as well make "patch" releases (incrementing the third number) often, maybe even every time a nontrivial pull request comes in (although probably not more often than once every couple of weeks). I don't see any disadvantages of that, and it would enable us to react more nimbly to problems (like issue #37 mentioned above).  Your thoughts?

3) conda.  I've been playing with the "conda recipes" I mentioned in my email to you a couple of weeks ago, and I've got them mostly working.  I've got precompiled binaries for slycot up on binstar.org, at least for linux.  I am having some trouble getting it to work on mac, but I hope to have that figured out soon.  That will make it much easier for users to install slycot: they'd just need to say
	conda install -c https://conda.binstar.org/cwrowley slycot
and would not need a fortran compiler.  Already this is a big improvement for the Travis CI builds, since they don't need to compile all the SLICOT stuff every time (which was the biggest bottleneck).  I've got that working in my fork, and I'll send a pull request over soon once I clean things up.

4) Version numbering.  While I was doing the conda stuff in my own fork, I simplified/streamlined the way the version numbers are specified.  The issue is that I didn't want to have to manually specify version numbers in several different places (e.g., in setup.py for PyPI, and in the conda "recipe", and in the git repo).  This has led to confusion in the past (see #1 above).  So the way I am doing this now is that the version number is specified in only one place, as a tag in the git repo.  So to specify a new version, you simply tag it in the repo as
	git tag -a 0.6.7
Then the version number is automatically obtained (from "git describe") when uploading to PyPI or to conda/binstar.  Another advantage of that is that a release is then automatically added to github, and is guaranteed to be consistent with what is on PyPI and conda.  Does that sound okay to you?  (I've been careful to make sure the version numbers conform to PEP 440, even for development versions.)

5) Website.  I'd like to try making a github pages website, as described in issue #34.  Any objections?

-clancy