You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add Project to the Python Package Index [sf#3] #19
Commented by sf-robot on 2011-07-06 20:20 UTC
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Commented by jgoppert on 2014-03-25 13:34 UTC
I did a test upload of the packge to PyPi with python setup.py register and had no issues. I took it back down becuase I figured that someone else might want to maintain it. I can maintain it if no one else is interested. I realize that this is still in beta, but it would be good to put something out there. We can warn that it is in beta in the setup.py and that will show up on the PyPi page.
Commented by jgoppert on 2014-04-01 18:08 UTC
I needed to be able to easily distribute my fork to my users so I put my fork up on pypi as control-jg so that users clearly realize it is a fork but can still easily access it. Hopefully in the future I can become more integrated into the dev team and I won't need to maintain a fork.
You can try it out and install it with:
pip install control-jg
Note that the installed module is still named control so it conflicts with previously installed versions of python-control.
Commented by scottlivingston on 2014-04-01 18:18 UTC
How is it not enough to post a tarball somewhere rather than occupy space on PyPI? E.g., GitHub can make tarballs dynamically from the repo as of a particular commit.
If we want to increase the user base pypi is a great way to do it and attract more developers. That is the strength of open source. If I show this to someone in my lab and say here.. type pip install control-jg.. done.. vs.. go to this url and download etc. it is more likely that they will use the software. I'm sure pypi can spare 111kb for us.
Commented by jgoppert on 2014-04-04 06:15 UTC
After much pain and effort I now have both slycot and python-control working with pypi. This required some significant changes. Currently they are both building every commit and pull request on travis-ci and running unit testing. We should add coverage testing when we get a chance. The hooks are already there for coverage testing from the numpy setup.py/ run_tests.py scripts. The travis-ci build tags are pretty handy and display the current status of building on the branch. Because the testing is building the dependencies from scratch in a virtual env, the build of slycot takes about 5 minutes, and the build of python-control, which also has to build slycot/matplotlib etc., takes about 30 min. Maybe we should not fail if we can't import matplotlib ect. for now to speed this test time up.
python-control
Travis-ci displaying current build status of jgoppert/python-control/master
This shows failing because skipIf isn't supported for unittest in python 2.6. You can see this from the build logs if you follow the link.
If you want to see the current difference in our forks here is the link: jgoppert/python-control@upstream-svn...master (note that this is a moving target, but this is typical for a pull request) If I push any more commits it will be to fix unit testing on travis-ci. There were some dependencies like matplotlib that needed to be installed for all the unit testing to work.
The setup.py's are based on the numpy setup.py so it is very easy to add extensions etc. as needed and they are already well proven for various python version. Travis-ci is building both packages and dependencies from scratch with pip for python 2.6, 2.7, 3.2, and 3.3
In the python-control package info I made it very clear that the python-control package was a fork and whenever you guys want to put up a package of master I will turn over maintenance on pypi to you. I also contacted everyone working on Slycot and told them the same thing. I imagine it will take some time for you to sort through the patch that made all of this work. But I think it will be well worth it.
Now that this repository is in sync with James's fork, we are probably ready to shift the pypi link to point here. @jgoppert and @murrayrm, do you agree? Does one of you want to make that switch?
I went ahead and uploaded it to pypi since there is no significant difference from what was up there currently. If you guys sign up on pypi and tell me your username I will give you admin rights to manage the package. You can upload a new version with the command:
Activity
murrayrm commentedon Aug 9, 2014
Commented by murrayrm on 2011-06-22 19:35 UTC
Will plan for doing this in the 1.0 release, when the package is beyond the beta stage.
[-]Add Project to the Python Package Index[/-][+]Add Project to the Python Package Index [sf#3][/+]murrayrm commentedon Aug 9, 2014
Commented by sf-robot on 2011-07-06 20:20 UTC
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
murrayrm commentedon Aug 9, 2014
Updated by murrayrm on 2012-09-04 04:57 UTC
murrayrm commentedon Aug 9, 2014
Commented by murrayrm on 2012-09-04 04:57 UTC
Moving this feature request off of the closed list. Should still be active.
murrayrm commentedon Aug 9, 2014
Commented by jgoppert on 2014-03-25 13:34 UTC
I did a test upload of the packge to PyPi with python setup.py register and had no issues. I took it back down becuase I figured that someone else might want to maintain it. I can maintain it if no one else is interested. I realize that this is still in beta, but it would be good to put something out there. We can warn that it is in beta in the setup.py and that will show up on the PyPi page.
murrayrm commentedon Aug 9, 2014
Commented by jgoppert on 2014-04-01 18:08 UTC
I needed to be able to easily distribute my fork to my users so I put my fork up on pypi as control-jg so that users clearly realize it is a fork but can still easily access it. Hopefully in the future I can become more integrated into the dev team and I won't need to maintain a fork.
You can try it out and install it with:
pip install control-jg
Note that the installed module is still named control so it conflicts with previously installed versions of python-control.
murrayrm commentedon Aug 9, 2014
Commented by scottlivingston on 2014-04-01 18:18 UTC
How is it not enough to post a tarball somewhere rather than occupy space on PyPI? E.g., GitHub can make tarballs dynamically from the repo as of a particular commit.
Of course, you can do all of this (python-control is open source) but it seems strange to have https://pypi.python.org/pypi/control-jg/0.6e list you as the author and to only have a link to http://python-control.sourceforge.net/ rather than your fork on GitHub.
murrayrm commentedon Aug 9, 2014
Commented by scottlivingston on 2014-04-01 18:18 UTC
I just found the URL to your Git repo. My original comment still stands.
murrayrm commentedon Aug 9, 2014
Commented by jgoppert on 2014-04-01 18:58 UTC
Here is the pkg info: https://pypi.python.org/pypi?name=control-jg&version=0.6e&:action=display_pkginfo
If we want to increase the user base pypi is a great way to do it and attract more developers. That is the strength of open source. If I show this to someone in my lab and say here.. type pip install control-jg.. done.. vs.. go to this url and download etc. it is more likely that they will use the software. I'm sure pypi can spare 111kb for us.
murrayrm commentedon Aug 9, 2014
Commented by jgoppert on 2014-04-04 06:15 UTC
After much pain and effort I now have both slycot and python-control working with pypi. This required some significant changes. Currently they are both building every commit and pull request on travis-ci and running unit testing. We should add coverage testing when we get a chance. The hooks are already there for coverage testing from the numpy setup.py/ run_tests.py scripts. The travis-ci build tags are pretty handy and display the current status of building on the branch. Because the testing is building the dependencies from scratch in a virtual env, the build of slycot takes about 5 minutes, and the build of python-control, which also has to build slycot/matplotlib etc., takes about 30 min. Maybe we should not fail if we can't import matplotlib ect. for now to speed this test time up.
python-control
Travis-ci displaying current build status of jgoppert/python-control/master
This shows failing because skipIf isn't supported for unittest in python 2.6. You can see this from the build logs if you follow the link.
slycot
Travis-ci displaying current build status of jgoppert/Slycot/master
The setup.py's are based on the numpy setup.py so it is very easy to add extensions etc. as needed and they are already well proven for various python version. Travis-ci is building both packages and dependencies from scratch with pip for python 2.6, 2.7, 3.2, and 3.3
https://github.com/numpy/numpy/blob/master/setup.py
In the python-control package info I made it very clear that the python-control package was a fork and whenever you guys want to put up a package of master I will turn over maintenance on pypi to you. I also contacted everyone working on Slycot and told them the same thing. I imagine it will take some time for you to sort through the patch that made all of this work. But I think it will be well worth it.
cwrowley commentedon Aug 12, 2014
Now that this repository is in sync with James's fork, we are probably ready to shift the pypi link to point here. @jgoppert and @murrayrm, do you agree? Does one of you want to make that switch?
jgoppert commentedon Aug 12, 2014
I went ahead and uploaded it to pypi since there is no significant difference from what was up there currently. If you guys sign up on pypi and tell me your username I will give you admin rights to manage the package. You can upload a new version with the command:
python setup.py sdist upload
cwrowley commentedon Aug 13, 2014
I just signed up for pypi and my userid is cwrowley.
jgoppert commentedon Aug 13, 2014
I took myself off as owner and set it to @murrayrm. I put @cwrowley and myself as maintainers.
slivingston commentedon Oct 13, 2014
@jgoppert, it appears that you are still listed as owner at https://pypi.python.org/pypi/control, in addition to @murrayrm, despite your statement that you "took [yourself] off as owner."
jgoppert commentedon Oct 13, 2014
I just fixed it. It appears when you add yourself as maintainer it doesn't remove yourself as owner which is kind of odd, that wasn't my intention.
murrayrm commentedon Nov 28, 2014
There's an e-mail discussion on the developer's mailing list related to this:
https://sourceforge.net/p/python-control/mailman/message/33090082/
Next step is to push v0.6.5 (current master) out onto PyPI at the same time as generating a source code release on SourceForge.
cwrowley commentedon Apr 6, 2015
I just uploaded 0.7.0 to PyPI (and binstar).