release on PyPI

[johnyf]

After some minor improvements (mainly logistics) the initial version will be released on PyPI to become available for automated installation through pip, easy_install or python setup.py install of a package that depends on it.

Before release a sandbox version can be found on testpypi.

[necozay]

What is the planned date for this release? I think we should have this up and running before the next TuLiP release.

[johnyf]

My suggestion is to avoid making any changes for the initial polytope release, so that it is exactly the same with the old one. This way people using older code can adapt their imports and use the first version of polytope. There is no planned date, releasing it on PyPI requires just two commands (same as for testpypi), I agree that it should be released before (or together with) tulip. A motivation for releasing it right away is to reserve the name on PyPI. If there is consensus I can do that.

[necozay]

I just did a fresh install of tulip from the master branch, together with polytope from its master branch and the examples seem to work fine. We might want to decide on the dependencies before the release:

• the minimum NumPy version polytope requires is currently 1.7 according to setup.py but I guess it should be compatible with earlier versions of NumPy as well.
• polytope requires networkx; as far as I remember, we can make this optional. But if we feel that it is going to be required in the future, we might keep it as is as well.

[johnyf]

There are 2 places that lightly use networkx:

• plot_partition uses nx.to_numpy_matrix to accept graphs as input.
• MetricPartition subclasses nx.Graph besides Partition. This because it abstracts the metric into a graph. Although currently this is not being used and the adj attribute is being used, after the initial release and when tulip.abstract.discretization.discretize is rewritten, I'd like to replace adj with operations on the graph itself. This is much more natural, if one thinks of it discretize becomes a graph rewriting function, and such an implementation is more robust to bugs because it will use the existing networkx methods. Moreover, it will avoid copying adjacency matrices and padding nodes, because it will just remove and add nodes iteratively. Also k-hop neighbor information (trans argument to discretize) will be easier to fetch.

[slivingston]

For posterity, discussion about dependency versions for TuLiP in tulip-control/tulip-control#48 is relevant.

[johnyf]

b2c9ccda3969208ce7ee277b6c233c9ad09636f6 is the initial release v0.1.0 and can be found on PyPI.