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

[Richard M. <mu...@cd...>]

Thanks for picking up all of these threads, Clancy!

* PyPI: I think we definitely want to get python-control working on PyPI.  Tagging the current version as 0.6.7 to make sure we don’t get a version naming clash seems like a good approach.

* Releases: updating the patch number (third digit) and making relatively frequent release seems like a good way to go.  We can update the minor number when there are significant enough changes (or enough patches) that we think people should definitely grab the latest release.  Not sure how often to do that (every 6 months?).

* Conda: this sounds like a nice way to get slycot without a FORTRAN compiler.  I just updated my laptop and remembered yet again that it is a bit of a hassle to deal with installing gfortran on the Mac.  Having a binary release would be a big help.  Though I still think we should move away from SLICOT over time when we can.

* Versioning: the new scheme sounds like a huge improvement.  I may grab that one for use in some other projects!

* Website: given that we have almost nothing now, trying out the github pages sounds like a great idea.  At some point this might trigger a move away from SourceForge, since from James Goppert’s github page it looks like you get get tar files, etc in a very simple way.

Would love to hear comments from others on the list.

-richard

> On 3 Apr 15, at 08:27, Clancy Rowley <cwr...@pr...> wrote:
> 
> 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
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> python-control-developers mailing list
> pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-control-developers